Host attestation

ABSTRACT

A service provider provides virtual computing services using a fleet of one or more host computer systems. Each of the host computer systems may be equipped with a trusted platform module (“TPM”). The service provider, the host computer systems, and the virtual computing environments generate attestations that prove the integrity of the system. The attestations are signed with a one-time-use cryptographic key that is verifiable against the public keys of the service provider, a host computer system, and a virtual computing environment. The public key of the host computer system is integrated into a hash tree that links the public key of the host computer system to the public key of the service provider. The public key of the virtual computing environment is signed using a one-time-use graphic key issued to the host computer system that hosts the virtual computing environment.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/298,867, filed on Mar. 11, 2019, entitled “HOST ATTESTATION,” whichis a divisional of U.S. patent application Ser. No. 15/389,771, filed onDec. 23, 2016, now U.S. Pat. No. 10,229,270, entitled “HOSTATTESTATION,” which is incorporated herein by reference for allpurposes.

This application incorporates by reference for all purposes the fulldisclosures of U.S. patent application Ser. No. 15/390,176, filed Dec.23, 2016, now U.S. Pat. No. 10,218,511, entitled “SIGNATURE DELEGATION,”U.S. patent application Ser. No. 15/946,614, filed Apr. 5, 2018, nowU.S. Pat. No. 10,129,034, entitled “SIGNATURE DELEGATION,” U.S. patentapplication Ser. No. 15/389,686, filed Dec. 23, 2016, now U.S. Pat. No.10,230,525, entitled “PUBLIC KEY ROLLUP FOR MERKLE TREE SIGNATURESCHEME,” U.S. patent application Ser. No. 15/390,205, filed Dec. 23,2016, now U.S. Pat. No. 10,237,249, entitled “KEY REVOCATION,” and U.S.patent application Ser. No. 15/390,214, filed Dec. 23, 2016, now U.S.Pat. No. 10,243,939, entitled “KEY DISTRIBUTION IN A DISTRIBUTEDCOMPUTING ENVIRONMENT.”

BACKGROUND

For many businesses, third-party computing resource service providersare an important part of their computing infrastructure. Many businessesdeploy application programs to virtual computing environments providedby third-party computing resource service providers. As the resourcedemands of a particular application change over time, businessadministrators are able to scale each virtual computing environment upor down as needed. However, when using virtual computing environments inthis way, it is important for the user of the virtual computingenvironment to be able to confirm that the computing environmentcomplies with an appropriate configuration. For example, beforedeploying an application or interacting with a service hosted on avirtual computer system, a customer may desire proof that the virtualcomputer instance is configured with an authentic image, that the hostof the virtual computer instance is properly configured, and that thehost of the virtual computer instance is owned by the computing resourceservice provider.

Protecting the integrity of digital signatures and encryptedcommunications is an important problem. Many digital signatures andencrypted communications rely on cryptographic keys that are controlledby a central authority. The central authority maintains control over thecryptographic keys which are used to generate digital signatures andperform other cryptographic operations. If the central authorityoperates as part of a distributed computing environment, cryptographicoperations may be performed by a variety of computing entities on behalfof the central authority. In such situations, the various computingentities acting on behalf of the central authority may apply digitalsignatures or establish cryptographically protected communicationsessions using a cryptographic key associated with the centralauthority. Therefore, controlling the distribution of cryptographic keysfrom the central authority to the various computing entities that act onthe behalf of the central authority is an important problem.

After the cryptographic keys are distributed or used it is sometimesdesired to revoke a particular cryptographic key. In such situations,entities verifying a digital signature or the validity of a particularcryptographic key contact a key-revocation authority to inquire whetheran associated cryptographic key is revoked or not. For a particular keygeneration and distribution scheme, it is important for the centralauthority, or delegate acting on behalf of the central authority, to beable to provide a provable indication that a particular cryptographickey is revoked.

BRIEF DESCRIPTION OF THE DRAWINGS

Various techniques will be described with reference to the drawings, inwhich:

FIG. 1 shows an illustrative example of an environment in which variousembodiments may be practiced;

FIG. 2 shows an illustrative example of a computer system that manageshost computer systems for a service provider;

FIG. 3 shows an illustrative example of a host computer system with atrusted platform module (“TPM”) that hosts one or more virtual computersystem instances;

FIG. 4 shows an illustrative example of a virtual computer systeminstance that is able to provide signed attestations of the computingenvironment;

FIG. 5 shows an illustrative example of a process that, as a result ofbeing performed by a service provider, a host computer system, and avirtual computer system instance, generates and distributes a set ofone-time-use cryptographic keys that are used by the virtual clientcomputer system;

FIG. 6 shows an illustrative example of a process that, as a result ofbeing performed by a client application and a virtual computer systeminstance, generates a signed attestation in response to a request fromthe client application;

FIG. 7 shows an illustrative example of a process that, as a result ofbeing performed by a client application, verifies a signed attestationprovided by a virtual client computer system;

FIG. 8 shows an illustrative example of a one-time-use cryptographic keythat includes secret key pairs and corresponding public key pairs;

FIG. 9 shows an illustrative example of signing a message with aone-time-use cryptographic key;

FIG. 10 shows an illustrative example of verifying a message with aone-time-use cryptographic key;

FIG. 11 shows an illustrative example of a secret key with an associatedpublic key;

FIG. 12 shows an illustrative example of a Merkle tree of one-time-usecryptographic keys;

FIG. 13 shows an illustrative example of a number of linked Merkle treesthat implement a cryptographic signature scheme for signingattestations;

FIG. 14 shows an illustrative example of an environment in which variousembodiments may be practiced;

FIG. 15 shows an illustrative example of a one-time-use cryptographickey that includes secret key pairs and corresponding public key pairs;

FIG. 16 shows an illustrative example of signing a message with aone-time-use cryptographic key;

FIG. 17 shows an illustrative example of verifying a message with aone-time-use cryptographic key;

FIG. 18 shows an illustrative example of a secret key with an associatedpublic key, and a revocation key with an associated revocation hashvalue;

FIG. 19 shows an illustrative example of a secret key with an associatedrevocation key that may be used to revoke the signature authority of thesecret key;

FIG. 20 shows an illustrative example of a Merkle tree of one-time-usecryptographic keys;

FIG. 21 shows an illustrative example of a Merkle tree of one-time-usecryptographic keys that includes revocation keys for revoking portionsof the tree;

FIG. 22 shows an illustrative example of a set of seed values that areused to generate a set of one-time-use keys and corresponding publickeys;

FIG. 23 shows an illustrative example of a set of one-time-usecryptographic keys that are generated from a tree of seed values;

FIG. 24 shows an illustrative example of a process that, as a result ofbeing performed by a signature authority, generates a seed tree thatsupports delegation of one-time-use cryptographic keys;

FIG. 25 shows an illustrative example of a process that, as a result ofbeing performed by a signature authority, delegates a portion ofone-time-use cryptographic keys to an authorized entity;

FIG. 26 shows an illustrative example of a process that, as a result ofbeing performed by an authorized entity, signs a message using aone-time-use cryptographic key provided by a signature authority;

FIG. 27 shows an illustrative example of a delegation service thatallocates and distributes blocks of cryptographic keys to one or moreauthorized delegates;

FIG. 28 shows an illustrative example of a process that, as a result ofbeing performed by a key distribution service and a delegate, allocatesa block of keys managed by the distribution service to be used by thedelegate;

FIG. 29 shows an illustrative example of a process that, as a result ofbeing performed by a signature authority and a delegated key generator,generates a subset of one-time-use keys specified by the signatureauthority using an intermediate seed value; and

FIG. 30 illustrates an environment in which various embodiments can beimplemented.

DETAILED DESCRIPTION

The current document describes a system that produces signedattestations as evidence of the integrity of a virtual computingenvironment. In various examples, a service provider provides virtualcomputing services to a customer in the form of one or more virtualcomputing environments hosted by one or more hosts operated by theservice provider. The virtual computing environment may be a virtualmachine, container runtime, on-demand execution engine, or otherapplication-execution environment. The service provider may host thevirtual computing environments on one or more server computer systems,server clusters, virtual computer systems, or other host computersystems. In order to confirm the trustworthiness and integrity of thevirtual computing environments provided, the customer may impose variousconstraints on the host computer systems used as well as the imagesinstalled on the virtual computing environments. In order to confirmthat the constraints are complied with, the customer may request anattestation from the service provider, the host computer system, and thevirtual computing environment.

The attestation may be generated and signed by a combination of theservice provider, the host computer system, and a virtual computingenvironment. In some examples, the service provider confirms theidentity and configuration of the host computer systems, the hostcomputer system confirms the integrity of the host operating environmentand the virtual runtime, and the virtual computing environment verifiesthe configuration of the customer's image. The resulting attestation maybe signed using a digital signature that is verifiable using public keysof one or more of the three attesting entities.

In some examples, the service provider uses remote attestation to verifythe integrity of host computer systems using a trusted platform module(“TPM”). A signature authority computer system operated by the serviceprovider contacts each host computer system operated by the serviceprovider and requests a signature of various hardware and softwareinstalled on the host computer system. A TPM on each host computersystem examines the host and generates the requested signature thatrepresents the hardware and software configuration. The TPM signs thesignature with a secret portion of an attestation identity key owned bythe TPM. In various examples, the attestation identity key is a digitalcertificate issued by a trusted certificate authority (“CA”), an RSApublic-private key pair, or a Merkle signature tree under the control ofthe TPM. The signature authority computer system receives the signaturesfrom the host computer systems and compares the signatures to referencesignatures in a database maintained by the service provider. The hostcomputer systems whose signatures match a valid reference signature inthe database are determined by the service provider to be properlyconfigured.

A Merkle tree of one-time-use cryptographic keys is generated for eachof the properly configured host computer systems. In some examples, theMerkle trees are generated by the service provider and provided to eachhost computer system. In another example, the Merkle trees are generatedby a TPM on each host and are stored within the TPM on each host. Theroot node of each Merkle tree acts as a public key for a correspondingindividual host computer system. The public keys corresponding to thehost computer systems are provided to the signature authority computersystem, and the signature authority computer system generates, for theservice provider, a Merkle tree of the public keys. The root of theservice provider's Merkle tree acts as a public key for the serviceprovider and is published by the signature authority computer system.

As described above, each properly configured host computer system isprovided with a Merkle tree of one-time-use cryptographic keys by theservice provider. In some examples, the virtual client manager on thehost computer system uses the provided one-time-use cryptographic keysto perform additional attestations. In some examples, the attestationsmay be used to confirm the integrity of the host operating system and/orthe virtual runtime. The virtual client manager uses the TPM on the hostcomputer system to generate a host-describing signature describing theconfiguration of the host operating environment and virtual runtime. TheTPM signs the host-describing signature with the attestation identitykey, and provides the signed signature to a virtual client managerrunning on the host computer system. The virtual client manager confirmsthe signature of the TPM using a public portion of the attestationidentity key, and compares the host-describing signature to a set ofapproved signatures maintained in a host signature database. In otherexamples, the virtual client manager provides signed code to the TPM,and the TPM executes the signed code to confirm that the host computersystem is configured in accordance with customer requirements.

When a virtual client manager on a properly configured host computersystem generates a new virtual computing environment, the virtual clientmanager provides the new virtual computing environment with a set ofone-time-use cryptographic keys arranged in a Merkle tree, and thevirtual client manager signs the root of the Merkle tree with one of theone-time-use keys provided to the virtual client manager by the serviceprovider. In some implementations, the virtual client manager provides avirtual client manager on the virtual computing environment with thecorresponding Merkle tree. In other implementations, the virtual clientmanager causes the TPM to generate and retain the Merkle trees, and thevirtual client manager grants each virtual computing environment accessto a Merkle tree by providing each virtual computing environment withaccess credentials to the TPM. In some examples, before signing the rootof the Merkle tree, the virtual client manager confirms the integrity ofthe virtual computing environment. For example, the virtual clientmanager may use the TPM to generate a signature of the image of thevirtual computing environment or portion of the virtual computingenvironment, and compare the signature against a database of approvedimage signatures. The signed root of the Merkle tree provided to thevirtual computing environment becomes the public key of the virtualcomputing environment.

Using the provided signed Merkle tree of one-time-use cryptographickeys, a virtual client manager in the virtual computing environment isable to produce signed attestations for customer applications, endusers, and other entities regarding the integrity of the virtualcomputing environment. In one example, a customer service is deployed toa virtual computing environment, and the customer service requests, fromthe virtual client manager running within the virtual computingenvironment, an attestation that the virtual computing environment is aproperly configured environment hosted by the service provider. Thevirtual client manager verifies various environment properties asrequested by the customer service (possibly using the TPM) and, usingthe credentials provided by the host computer system, accesses theMerkle tree of one-time-use keys provided by the host computer systemwhen the virtual computing environment was created. An unusedone-time-use key is selected from the Merkle tree and used to sign theattestation. The signed attestation is provided to the customer service.

The customer, end user, or client application may use the signedattestation to verify the state of the service provider, the hostcomputer system, and the virtual computing environment. The signature onthe attestation is confirmed by verifying the signature using the publickeys associated with the virtual computing environment. The root of theMerkle tree of the virtual computing environment is signed by the hostcomputer system. The signature of the root of the Merkle tree of thevirtual computing environment is verified against a public key of thehost computer system. The public key of the host computer system is aleaf node of the Merkle tree of the service provider and is verifiedagainst the public key of the service provider.

The current document describes methods of generating, distributing, andrevoking one-time-use cryptographic keys. One-time-use cryptographickeys may be generated and used as part of a Lamport signature scheme,Winternitz signature scheme, or other cryptographic one-time signaturescheme. Each one-time-use cryptographic key includes a secret key and anassociated public key or hash value. A signature authority pre-generatesa collection of one-time-use cryptographic keys that is used forgenerating digital signatures. The collection of one-time-usecryptographic keys is generated from a secret seed value, or in someimplementations, a set of related seed values, using a key-derivationmethod. The collection of one-time-use cryptographic keys is arranged ina Merkle tree, and hash values associated with the one-time-usecryptographic keys are used to cryptographically derive a root node ofthe Merkle tree which serves as a public key for the signatureauthority.

In some examples, the set of seed values is arranged in a tree structurethat corresponds to the structure of the Merkle tree. A master seedvalue corresponding to the root node of the Merkle tree is used togenerate a seed value for each child node of the root node using aone-way function. The seed value associated with each intermediate nodeis used to generate seed values for each child node. Seed valuesassociated with leaf nodes are used to generate cryptographic keys usinga key derivation function.

The signature authority is able to delegate signature authority to adelegate computing entity by providing a portion of the cryptographickeys to the delegate. The signature authority provides a subset of thecryptographic keys to the delegate by providing a seed valuecorresponding to a node of the Merkle tree to the delegate. Using theseed value, the delegate is able to generate the set of cryptographickeys that are children of the corresponding node of the Merkle tree. Inaddition to the seed value, the signature authority provides supportinginformation to the delegate. The supporting information includes thelocation of the seed value within the Merkle tree, the depth, fanout,and number of cryptographic keys in the Merkle tree, and intermediatehash values in the Merkle tree that are used to verify signaturesgenerated using the delegated cryptographic keys.

When a requester submits a signing request to the delegate, the delegatecomputing entity generates a digital signature on behalf of thesignature authority by selecting a cryptographic key pair that has notyet been used from the delegated set of keys, and generates a digitalsignature for a message provided by the requester. The delegate providesthe requester with the signature, the hashes of the cryptographic keypair, and the hashes associated with intermediate and adjacent nodes ofthe Merkle tree up to the root node of the signature authority. Afterproducing the digital signature, the delegate marks the selectedcryptographic key pair as having been used to generate a digitalsignature. In many implementations, the selected cryptographic key pairis used once and not reused. If the selected cryptographic key pair isreused, the cryptographic security of the digital signature is greatlyreduced with each successive use.

A recipient of the digital signature validates the digital signature bycalculating the hash value of the signature, confirming that the hashvalue matches the appropriate portions of the hashes corresponding tothe cryptographic key pair, and confirming the hashes of thecryptographic key pair by verifying the hashes of the intermediateMerkle tree nodes up to the root of the signature authority. If any ofthe checks fail, the digital signature is not valid.

In some examples, the signature authority retains an ability to revoke adigital signature or invalidate a particular cryptographic key. Toprovide for revocation of a particular cryptographic key, the signatureauthority determines a secret revocation value and a hash of the secretrevocation value. The hash of the secret revocation value (revocationhash), is hashed together with the hash of a particular cryptographickey to produce a leaf-node hash of a Merkle tree. The revocation hash ispublished with the hash of the secret cryptographic key to enableverification of signatures created with the secret cryptographic key. Torevoke the particular cryptographic key, the signature authoritypublishes the secret revocation value. When a recipient of the digitalsignature attempts to confirm the validity of the particularcryptographic key, the signature authority indicates that the particularcryptographic key is revoked and provides the secret revocation value asproof that the signature authority is the owner of the particularcryptographic key. The recipient of the digital signature can confirmthe secret revocation value by confirming that the hash of the secretrevocation value matches the published revocation hash, and that thehashes of the Merkle tree roll up to the published public key. In someimplementations, the signature authority provides secret revocationvalues for non-leaf nodes of the Merkle tree. By publishing a secretrevocation value of a non-leaf node, the signature authority may revokecryptographic keys and associated digital signatures that are childrenof the non-leaf node within the Merkle tree.

In some examples, the signature authority provides a key-distributionservice that distributes blocks of cryptographic keys to authorizedsigning delegates. An authorized signing delegate contacts thekey-distribution service and requests a block of cryptographic keys. Thenumber of cryptographic keys requested by a particular delegate is basedat least in part on a predicted volume of digital signatures to beproduced by the particular delegate. If the delegate performing digitalsignatures on behalf of the signature authority runs out of keys, thesignature authority may allocate additional cryptographic keys to thedelegate via the key-distribution service. The signature authoritymaintains a record of which keys have been distributed and used. In someimplementations, the signature authority monitors the digital signaturesproduced by signing delegates to ensure that cryptographic keys are notreused.

FIG. 1 shows an illustrative example of an environment in which variousembodiments may be practiced. A diagram 100 shows a system where signedattestations establish the integrity of a virtual computing environment.A service provider provides computing services to customers via a fleetof computer systems, storage systems, and other computinginfrastructure. A service provider computer system 102 maintains aservice provider key store 104. The service provider key store retainscryptographic information including cryptographic keys, hashes, anddigital certificates controlled by the service provider.

The service provider maintains a fleet of host computer systems thatincludes a host computer system 106. The host computer system 106 isused to provide virtual computing environments to customers of theservice provider. In some examples, the host computer system 106 is usedto provide virtual machines to customers. In another example, the hostcomputer system is used to provide an on-demand function executionservice. In yet another example, the host computer system is used tohost a container runtime that hosts containerized applications providedby customers. The host computer system 106 maintains a host key store108 that retains cryptographic keys, hashes, digital certificates, orother cryptographic information associated with the host computer system106. In some implementations, the host computer system 106 includes atrusted platform module (“TPM”) and the host key store 108 resideswithin the TPM. In another implementation, the host computer system 106retains the host key store 108 and a memory outside the TPM, and the TPMapplies a signature to the host key store 108.

The host computer system 106 hosts one or more virtual computingenvironments including the virtual computer system 110. The virtualcomputer system 110 is a virtual machine generated by the host computersystem 106 and may be loaded with a customer image by the host computersystem 106. The virtual computer system 110 accesses a VM key store 112.The VM key store may be retained in memory associated with the virtualcomputer system 110 or within a TPM on the host computer system 106. Thevirtual computer system 110 includes an attestation service that may beaccessed by applications, end users, or other entities. The attestationservice provides signed attestations that the virtual computer system110, the host computer system 106, and the service provider computersystem 102 are properly configured in accordance with customerrequirements.

A verifiable key structure linking the service provider key store 104,the host key store 108, and the VM key store 112 is generated as aresult of the deployment and configuration of the host computer system106 and the virtual computer system 110. The service provider deploysand allocates a number of host computer systems. The host computersystems are installed with host images and configured to act as host forvirtual computing environments. Each host computer system includes aTPM. The service provider uses the TPM to confirm the properconfiguration of each host computer system. In some implementations, theTPM generates a checksum of software and hardware configuration, and thechecksum is confirmed against a database of approved checksumsmaintained by the service provider. In some implementations, the TPMensures that only applications signed by an approved authority areexecuted on the host computer system 106. Each host computer systemgenerates a Merkle tree of one-time-use cryptographic keys to be used bythe host computer system. The root of the Merkle tree is published tothe service provider. If the service provider determines that the hostcomputer system 106 is properly configured, the root value of the Merkletree associated with the host computer system 106 is gathered with otherroot values of Merkle trees associated with other computer systems toform a service provider Merkle tree. The service provider Merkle treerolls up to a service provider hash. The service provider hash ispublished as a public key for the service provider.

When the host computer system 106 generates a new virtual computersystem, the host computer system 106 causes a Merkle tree ofone-time-use cryptographic keys to be generated for the virtual computersystem. The root of the Merkle tree is signed using one of theone-time-use cryptographic keys generated above. In someimplementations, the host computer system 106 performs various checks onthe virtual computer system before signing the root of the Merkle treeof the virtual computer system 110. In some examples, the Merkle tree ofone-time-use cryptographic keys is maintained by the virtual computersystem 110 in the VM key store 112. In other implementations, the Merkletree of one-time-use cryptographic keys is maintained in a TPM on thehost computer system 106, and the virtual computer system 110 is grantedaccess to the TPM to access the set of one-time-use cryptographic keys.

A client computer system 114 requests an attestation from the virtualcomputer system 110. The virtual computer system 110 performs therequested attestation, and signs the requested attestation with one ofthe one-time-use cryptographic keys provided to the virtual computersystem 110. In some implementations, the virtual computer system 110performs the requested attestation using a TPM on the host computersystem 106, and the TPM signs the attestation with a one-time-use keyassigned to the virtual computer system and retained by the TPM. Thesigned attestation is returned to the client computer system 114.

The signature on the attestation is verified by verifying that thesignature on the attestation is properly generated with a one-time-usekey from the Merkle tree associated with the virtual computer system110. The root hash of the Merkle tree associated with the virtualcomputer system 110 is signed by the host computer system 106 using aone-time-use cryptographic key that links up to the root of a Merkletree on the host key store 108. The root of the Merkle tree on the hostkey store 108 is a leaf node of the Merkle tree generated by the serviceprovider and retained on the service provider key store 104. Therefore,the signature on the Merkle tree on the VM key store 112 can be verifiedup to the root node of the Merkle tree maintained on the serviceprovider key store 104, which serves as the public key of the serviceprovider. In various implementations, verification of the attestationmay be used to indicate that the service provider computer system 102has confirmed that the host computer system 106 is a properly configuredhost computer system operated by the service provider, that the hostcomputer system 106 is hosting the virtual computer system 110, and thatthe virtual computer system 110 has confirmed a valid operatingenvironment.

FIG. 2 shows an illustrative example of a computer system that manageshost computer systems for a service provider. A block diagram 200illustrates a structure of a service provider computer system 202 thatprovides host-management services for a service provider using a hostmanagement service 204. The host management service 204 includes a hostmanager 206, the key publication service 208, and host image manager210. The host manager 206 is a service that tracks and manages acollection of host computer systems owned and operated by the serviceprovider. The host manager 206 includes a database of host computersystems, and communicates management instructions to an agent on eachhost to perform configuration and other management tasks. The keypublication service 208 is a network-accessible service that providescryptographic hashes used for verifying digital signatures generatedusing cryptographic keys that are based at least in part on a public keyof the service provider. The host image manager 210 works with the hostmanager 206 to provide imaging services to the host computer systemsunder the control of the service provider. The host management service204 includes a host signature database 212. The host signature database212 contains a database of environment signatures for the host computersystems that are under management. The service provider computer system202 maintains a database of public keys 214 that are been assigned tohost computer systems, a Merkle tree 216 of hashes cryptographicallyderived from the database of public keys 214, and a public key 218 atthe root of the Merkle tree that acts as the public key of the serviceprovider. Cryptographically derived from a value means using a one-wayfunction at least once using inputs that are the values or derived fromthe values (possibly cryptographically derived from the values).

The host manager 206 contacts the hosts that are managed by the serviceprovider, and verifies the configuration of each host using a TPM oneach host. The configuration of the hosts may be verified by comparing aconfiguration signature provided by a TPM on each host againstinformation in the host signature database 212. If a particular host isnot configured, or is improperly configured, the host image manager 210may be used to apply a clean image to the particular host. The hostmanager 206 retrieves a public key from each host that is determined tobe properly configured, and the public keys are stored in the databaseof public keys 214. The host manager 206 generates the Merkle tree 216from the public keys, resulting in the public key 218 of the serviceprovider. The key publication service 208 publishes the public key 218of the service provider, the Merkle tree 216, and the database of publickeys 214. The key publication service 208 enables recipients of digitalsignatures to verify digital signatures against the public key 218 ofthe service provider.

FIG. 3 shows an illustrative example of a host computer system with atrusted platform module (“TPM”) that hosts one or more virtual computersystem instances. A block diagram 300 shows a host computer system 302that is operated by a service provider. The host computer system 302 maybe a server computer, server cluster, computer appliance, or othercomputing device capable of hosting one or more virtual computingenvironments. The host computer system 302 includes a trusted platformmodule 304. In general, a trusted platform module is a hardware devicecomprising a secure cryptoprocessor and associated memory that providessupport for encryption, decryption, a key generation, and othercryptographic operations in a protected tamper-resistant environment.The host computer system 302 also includes a virtual environment manager305, and a virtualization runtime 306. The virtual environment manager305 is a service running on the host computer system 302 that managesthe creation, verification, and configuration of virtual computingenvironments on the host computer system 302. The virtual environmentmanager 305 interacts with a virtualization runtime 306. Thevirtualization runtime 306 is a runtime that supports virtual machines,container services, on-demand function execution, or other virtualcomputing environment. In the example shown in FIG. 3 , thevirtualization runtime 306 implements the first virtual computer systeminstance 308 and a second virtual computer system instance 310. Thevirtualization runtime 306 may support additional virtual computersystems, virtual machines, container runtimes, and other virtualcomputing environments.

The trusted platform module 304 includes an authentication service 312and an authorization service 314. The authentication service 312 is aservice within the trusted platform module that authenticates theidentity of entities attempting to use the trusted platform module 304.The identity of entities attempting to use the trusted platform module304 may be verified using digital certificates, passwords, or othercredentials. The authorization service 314 determines whether aparticular entity is authorized to perform a particular cryptographicoperation. The authorization service 314 maintains a database ofauthorized entities and determines whether each request submitted to thetrusted platform module 304 is allowable. The trusted platform moduleincludes a cryptographic processor 316 and secure storage 318. Invarious implementations, the cryptographic processor may performencryption, decryption, signing, key generation, random numbergeneration, cryptographic hash determination, and other cryptographicoperations. The secure storage 318 contains cryptographic keys,attestation keys, cryptographic hashes, Merkle trees, and othercryptographic information used by the trusted platform module 304.

The trusted platform module 304 contains a Merkle tree of one-time-usecryptographic keys that are linked into a corresponding Merkle treemaintained by the service provider. The Merkle tree within the trustedplatform module 304 has a root node 320 that acts as a public key of thehost computer system 302. The root node 320 is linked to a Merkle treeof hashes 322 that leads to a set of one-time-use cryptographic keys324. The set of one-time-use cryptographic keys 324 is used by thevirtual environment manager 305 to sign root nodes of hash trees thatare associated with individual virtual computing environments. The firstvirtual computer system instance 308 includes a first hash tree ofone-time-use cryptographic keys 326 and the second virtual computersystem instance 310 includes a second hash tree of one-time-usecryptographic keys 328. The first hash tree of cryptographic keys 326has a first root node that is signed using one of the one-time-usecryptographic keys 324 of the host computer system 302. The second hashtree of graphic keys 328 has a second root node that is signed using adifferent one-time-use cryptographic key of the one-time-usecryptographic keys 324.

Each time the virtual environment manager 305 generates a new virtualcomputing environment, the virtual environment manager 305 causes thenew virtual computing environment to generate an associated hash tree ofone-time-use cryptographic keys. The virtual environment manager 305 mayuse the trusted platform module 304 to verify the integrity of the newvirtual computing environment. If the virtual environment manager 305determines that the integrity of the new virtual computing environmentis valid, the virtual environment manager 305 retrieves the root hash ofthe hash tree of one-time-use cryptographic keys of the new virtualcomputing environment, and signs the root hash with one of the hostcomputer system's one-time-use cryptographic keys 324. The signed roothash is returned to the new virtual computing environment and may serveas proof that the new virtual computer system is running on a properlyconfigured host computer system operated by the service provider.

FIG. 4 shows an illustrative example of a virtual computer systeminstance that is able to provide signed attestations of the computingenvironment. A block diagram 400 shows a virtual computer systeminstance 402 that is hosted by a host computer system operated by aservice provider. The virtual computer system instance 402 includes aclient operating system 404 that supports a client service 406. In otherexamples, the client operating system 404 supports a user program, anetwork service, or other client application deployed by a customer. Theclient operating system 404 includes a virtual client manager 408. Thevirtual client manager 408 receives an attestation request from theclient service 406.

In response to the attestation request, the virtual client manager 408performs operations to confirm the integrity of the virtual computersystem instance. In some implementations, the virtual client manageruses the TPM installed on the host computer system that hosts thevirtual computer system instance 402 to verify the configuration of thevirtual computer system instance 402. If the virtual client manager 408determines that the virtual computer system instance 402 is properlyconfigured, the virtual client manager 408 signs an attestation to thateffect using a digital signature generated with a one-time-use keyselected from a set of one-time-use keys 414 issued to the virtualcomputer system instance 402 by the host of the virtual computer systeminstance 402. The set of one-time-use keys 414 is linked via a hash tree412 to a root node of the hash tree 410. The root node of the hash tree410 is signed using a one-time-use key owned by the host computer systemof the virtual computer system instance 402. The signed attestation isreturned to the client service 406.

The client service 406 retrieves the public key of the virtual computersystem instance 402 from the client operating system 404 and verifiesthat the signature of the attestation is valid for the root node of thehash tree 410. To confirm the root node of the hash tree 410, the clientservice 406 retrieves verification hashes from a publication serviceoperated by the service provider, and retrieves verification hashes fromthe host computer system. In some examples, verification hashesassociated with the host computer system are retrieved from the TPM onthe host computer system. The client service 406 verifies that thesignature on the root node of the hash tree 410 can be verified usinghash trees of the host computer system and the service provider to aroot public key of the service provider. In this way, the client service406 may verify that the integrity of the virtual computer systeminstance 402 has been verified by the virtual client manager 408, thehost computer system of the virtual computer system instance 402, andthe service provider.

FIG. 5 shows an illustrative example of a process that, as a result ofbeing performed by a service provider, a host computer system, and avirtual computer system instance, generates and distributes a set ofone-time-use cryptographic keys that are used by the virtual clientcomputer system. A swim diagram 500 illustrates a process that begins atblock 502 with a service provider computer system requesting anattestation from the host computer system. The service provider computersystem may act as a signature authority for the service provider. Invarious examples, the attestation may be a request for a signature thatrepresents the hardware and software configuration of the host computersystem. In other examples, the attestation may be a request forconfiguration information relating to the host computer system. In yetanother example, the attestation request may include instructions to beexecuted on a trusted platform module on the host computer system.

The host computer system receives the request from the service providercomputer system, and the host computer system uses a trusted platformmodule on the host computer system to verify 504 the host configuration.In some examples, the TPM generates a signature representing thehardware and software configuration of the host computer system, and theTPM compares the signature against one or more approved signatures thatcorrespond to verifiable hardware and software configurations. In someimplementations, the authorized signatures are provided by the serviceprovider computer system with the request. In other implementations, theauthorized signatures are retained on the TPM on the host computersystem.

If the host computer system is able to verify the hardware and softwareconfiguration of the host computer system, the host computer systemgenerates 506 a set of one-time-use cryptographic keys for use by thehost computer system. In some examples, the set of one-time-usecryptographic keys is comprised of Lamport or Winternitz keys. The hostcomputer system generates a hash tree (also known as a Merkle tree)using hashes generated from the set of one-time-use cryptographic keysas leaf nodes, and linking to a root node hash that serves as a publickey for the host computer system. At block 508, the host computer systemuses the TPM to generate a signed attestation. In some examples, thesigned attestation is a signature describing the hardware and softwareconfiguration of the host computer system that is signed using a privatecryptographic key belonging to the TPM. At block 510, the host computersystem provides the signed attestation and the root node hash to theservice provider computer system.

The service provider computer system receives the signed attestationfrom the host computer system and verifies 512 both the signature on theattestation and the value of the attestation itself. In some examples,the service provider computer system uses a public key of the TPM toverify the signature on the attestation. The attestation itself isverified against a set of approved signatures maintained by the serviceprovider computer system. The service provider computer system attemptsto collect verifiable attestations from each of the host computersystems managed by the service provider. At block 514, the serviceprovider computer system collects the root node hashes of the hostcomputer systems that have also provided verified attestations to theservice provider computer system. The root node hashes of the hostcomputer systems are used by the service provider computer system togenerate 514 a service-provider hash tree of the root node hashes. Theservice-provider hash tree has a root hash that is used as a public keyfor the service provider. At block 516, the service provider computersystem publishes the root hash of the service-provider hash tree alongwith other hashes of the service-provider hash tree. Publication of theservice-provider hash tree enables recipients of digital signaturesgenerated with one-time-use keys controlled by host computer systems toverify the digital signatures against the public key of the serviceprovider.

The host computer system uses the one-time-use keys generated at block506 to provide additional one-time-use keys to virtual computer systeminstances managed by the host computer system. At block 518, the hostcomputer system creates the virtual computer system instance andverifies the configuration of the virtual computer system instance. Thehost computer system verifies the integrity of the virtual computersystem instance. In some examples, the host computer system uses the TPMto verify parts of the virtual runtime on the host computer system. Inother examples, the host computer system uses the TPM to verify theimage running on the virtual computer system instance. If the integrityof the virtual computer system instance cannot be verified, the virtualcomputer system instance is not provided with cryptographic keys thatare signed by the host computer system. At block 520, if the integrityof the virtual computer system instance is verified, the host computersystem generates a set of one-time-use cryptographic keys for use by thevirtual computer system instance. Hashes of the set of one-time-usecryptographic keys are used to generate a hash tree that links the setof one-time-use cryptographic keys to a root hash which serves as apublic key for the virtual computer system instance. At block 522, thehost computer system signs the public key of the virtual computer systeminstance (root hash) using one of the one-time-use cryptographic keysgenerated by the host computer system at block 506.

The number of one-time-use cryptographic keys generated for use by thevirtual computer system instance can be determined by the host computersystem based on the projected needs of the individual virtual computersystem instance. If additional keys are needed by the virtual computersystem instance, the host computer system may generate an additional setof one-time-use cryptographic keys for the virtual computer systeminstance, generate an additional hash tree of the additional set ofone-time-use cryptographic keys, and sign the new root of the additionalhash tree.

The one-time-use cryptographic keys generated by the host computersystem at block 520 are made available to the virtual computer systeminstance. In some examples, the one-time-use cryptographic keys and theassociated hash tree are provided to the virtual computer systeminstance, and the virtual computer system instance receives and stores526 the one-time-use cryptographic keys and the associated hash treewithin the virtual computer system instance. In other examples, theone-time-use cryptographic keys are retained in a TPM on the hostcomputer system, and TPM credentials are provided to the virtualcomputer system instance that allows the virtual computer systeminstance to access the one-time-use cryptographic keys on the TPM.

FIG. 6 shows an illustrative example of a process that, as a result ofbeing performed by a client application and a virtual computer systeminstance, generates a signed attestation in response to a request fromthe client application. A swim diagram 600 illustrates a process thatbegins at block 602 with a client application requesting an attestationfrom the virtual computer system instance. The request may include arequest for a signature representing the configuration of the virtualcomputer system instance, or the request may include a set ofconstraints to be evaluated and certified by the virtual computer systeminstance.

At block 604, the virtual computer system instance receives the requestand acquires a configuration signature for the virtual computer systeminstance. In various examples, the configuration signature is a hash,checksum, or cyclic redundancy code (“CRC”) generated using measures ofhardware and software configuration of the virtual computer systeminstance. In some examples, the virtual computer system instancegenerates the configuration signature based on the image running on thevirtual computer system instance. In another example, the virtualcomputer system generates the signature based on cryptographic hashes ofone or more software components running within the virtual computersystem instance.

At block 606, the virtual computer system instance acquires aconfiguration signature for the host computer system hosting the virtualcomputer system instance. In some examples, the configuration signatureof the host computer system is acquired by querying a service on thehost computer system. In other examples, the configuration signature ofthe host computer system is acquired by generating a new host signatureusing a TPM on the host computer system. In yet another example, thevirtual computer system instance queries the host computer system forthe configuration signature, and the host computer system generates anew host signature if the configuration of the host computer system haschanged. At block 608, the virtual computer system acquires aconfiguration signature for the service provider that operates the hostcomputer system. In some examples, the configuration signature of theservice provider is acquired by querying a service on a computer systemoperated by the service provider.

At block 610, the virtual computer system instance selects an unused keyfrom the set of one-time-use cryptographic keys provided to the virtualcomputer system instance by the host computer system. The virtualcomputer system instance marks the selected key as used and generates612 a digital signature for the configuration signatures using theselected one-time-use cryptographic key. At block 614, the virtualcomputer system instance sends the signed configuration signatures tothe client application to be used as an attestation of system integrity.

The client application receives the signed attestation from the virtualcomputer system instance. At block 616, the client application verifiesthe signature on the attestation. In some examples, the signature on theattestation is verified by confirming the signature against the publickey of the virtual computer system instance, and then verifying thesignature on the public key of the virtual computer system instanceagainst the public key of the service provider. At block 618, the clientapplication examines the configuration signatures in the attestation anddetermines whether the configurations of the virtual computer systeminstance, the host computer system, and the service provider areacceptable. In some implementations, the client application retains alist of acceptable configuration signatures for the virtual computersystem instance, the host computer system, and the service provider andcompares the received configuration signatures against the list ofacceptable configuration signatures. If the received configurationsignatures are represented in the list of acceptable configurationsignatures, the virtual computing environment of the virtual computersystem instance is determined to be acceptable to the clientapplication.

FIG. 7 shows an illustrative example of a process that, as a result ofbeing performed by a recipient application, verifies a signedattestation provided by a virtual client computer system. A flowchart700 illustrates a process that begins at block 702 with a recipientapplication receiving a signed attestation from a service on a virtualcomputer system. At block 704, the recipient application usesinformation within the attestation to confirm that the configuration ofthe virtual computer system matches a configuration that is acceptableto the recipient application. In some implementations, the recipientapplication compares the configuration signature of the attestation to adatabase of acceptable configuration signatures maintained by theapplication. If the configuration information in the attestation isacceptable to the recipient application, execution advances to block 706and the recipient application verifies that the signature on theattestation is verifiable against a public key provided by the virtualcomputer system. In some implementations, the signature on theattestation is generated with a one-time-use cryptographic key, and thepublic key of the virtual computer system is a root of a hash tree builtfrom hashes that includes a hash of the one-time-use cryptographic key.

The recipient application confirms that the public key provided by thevirtual computer system is properly signed by the host computer systemand the service provider. At block 708, the recipient applicationconfirms that the signature on the public key of the virtual computersystem is properly signed by the host computer system. The signature onthe public key of the virtual computer system is signed using aone-time-use cryptographic key. The signature on the public key of thevirtual computer system is verified using a hash tree and public key(root node of the hash tree) generated by and associated with the hostcomputer system of the virtual computer system. The hash tree and publickey of the host computer system are published by the host computersystem. At block 710, the recipient application confirms that the publickey of the host computer system is verifiable against the public key ofthe service provider. The service provider publishes a hash tree havinga root node that represents the public key of the service provider. Thepublic key of the host computer systems that are associated with theservice provider are represented by the leaf nodes of the hash treepublished by the service provider. The recipient application verifiesthat the public key of the host computer system is in the hash treepublished by the service provider, and that the hash tree of the serviceprovider properly chains up to the public key of the service provider.

After verifying the contents of the attestation and the signature on theattestation, at block 712, the recipient application determines that theconfiguration of the virtual computer system is acceptable. In someexamples, the recipient application provides a challenge to the virtualcomputer system, and the virtual computer system signs the challengewith a digital signature. By verifying the digital signature against thepublic key of the host computer system and the service provider, therecipient application verifies that the service provider and the hostcomputer system have attested to the proper configuration of the virtualcomputing environment.

FIG. 8 shows an illustrative example of a one-time-use cryptographic keythat includes secret key pairs and corresponding public key pairs. Adiagram 800 shows a one-time-use key that is generated by a signatureauthority. The one-time-use key is comprised of a secret key pair 802and a public key pair 804. The secret key pair 802 includes a firstsecret key 806 and a second secret key 808. The first secret key 806 andthe second secret key 808 each consist of a number (n) of n-bit keys. Insome implementations, the first secret key 806 and the second secret key808 are random numbers generated by the signature authority. In otherimplementations, the signature authority generates the first secret key806 and the second secret key 808 from a secret seed value using a keyderivation function (“KDF”). In some implementations, the secret seedvalue is itself generated from another secret seed value managed by thesignature authority or owned by a superior signature authority.

The public key pair 804 includes a first public key 810 and a secondpublic key 812. The first public key 810 and the second public key 812each include a number (n) of n-bit hashes that correspond to the keys ofthe first secret key 806 and the second secret key 808. Each n-bit keyof the secret key pair 802 is used to generate a corresponding n-bithash of the public key pair 804. For example, the hash of the first keyof the first secret key 806 is the first hash of the first public key810. Each hash is generated with a cryptographic hash function orone-way function h(x)=y where y is easy to calculate for a given x, butx is computationally difficult to calculate for a given y. In someexamples, SHA256, MD5, BLAKE, or BLAKE2 hash functions are used togenerate the hashes. The public key pair 804 is published by thesignature authority.

FIG. 9 shows an illustrative example of signing a message with aone-time-use cryptographic key. A diagram 900 illustrates the signing ofa message 902 by a signature authority using a one-time-use key. Invarious examples, the message 902 may be a network packet, digitalcertificate, transactional record, media file, legal document, or othermessage submitted for signing by a requester. The signature authorityreceives the message 902 from the requester and determines an n-bitmessage hash 904 using a cryptographic hash function or other one-wayfunction. A one-way function or cryptographic hash has the property thatfor a given input, a hash value is relatively easy to calculate, but fora given hash value, an input that produces the given hash value iscomparatively difficult. In various examples, cryptographic hashfunctions such as SHA-256, MD-5, or BLAKE may be used as thecryptographic hash function.

To sign the message 902, the signature authority selects a one-time-usekey for use in generating the digital signature. In some examples, ifthe signature authority has exhausted the supply of one-time-use keys,the signature authority reports an error and does not sign the message902. In other examples, if the signature authority has used the supplyof one-time-use keys, a key may be selected for reuse. A particularcryptographic key may be selected for reuse based at least in part onthe number of times the particular key has been reused and theparticular secret keys used to generate previous signatures. In someimplementations, the signature authority maintains a key-use databasethat records the number of times each key has been used, and the digitalsignature generated with each key. In some examples, to locate a key forreuse, the signature authority may locate those keys that have been usedthe least number of times to generate digital signatures. In anotherexample, the signature authority is provided with the message to besigned, and the signature authority identifies a cryptographic key forreuse that, when generating a digital signature for the message, revealsthe lowest number of additional secret key portions of the availablereusable cryptographic keys.

The one-time-use key includes a secret key pair that includes a firstsecret key 906 and a second secret key 908. For each bit (m) of then-bit message hash 904, the signature authority selects either the m'thkey from the first secret key if the bit is a zero bit, or the m'th keyfrom the second secret key if the bit is a one bit. The selected keysare concatenated to form a digital signature 910 having n-squared bits.The digital signature 910 is provided to the requester. In addition tothe digital signature 910, the requester is provided with public keyinformation associated with the selected one-time-use key to support theverification of the digital signature 910. The public key informationmay include one or more hashes of a hash tree or Merkle tree that linkthe public key information to a public key of the signature authority.For each bit of the n-bit message hash 904, a secret key is chosen fromeither the first secret key 906 or the second secret key. For ‘zero’bits of the n-bit message hash 904, a secret key corresponding to thebit in the n-bit message hash is selected from the first secret key 906.For ‘one’ bits of the n-bit message hash 904, a secret key correspondingto the bit in the n-bit message hash is selected from the second secretkey 908. The bit position within the n-bit message hash 904 correspondsto the row (key number) within either the first secret key 906 or secondsecret key 908. In the example shown in FIG. 9 , for each bit of then-bit message hash, an arrow indicates the row of the particular secretkey (having n-bits) which is added to the resulting digital signature910.

FIG. 10 shows an illustrative example of verifying a message with aone-time-use cryptographic key. A diagram 1000 illustrates how arecipient of a signed message is able to verify a digital signature. Toverify the signed message, the recipient separates a digital signature1002 from the signed message. The digital signature 1002 has n-squaredbits, and the recipient divides the digital signature 1002 into n-keyportions of n-bits each. The recipient determines a hash of each keyportion and assembles the hashes into a hash sequence 1004 of n, n-bithashes.

Using information provided with the digital signature, the recipientidentifies the particular one-time-use-key used to generate the digitalsignature and requests related public key information from a signatureauthority. The signature authority provides the recipient with a publickey pair corresponding to the one-time-use key used to generate thedigital signature. The public key pair includes a first set of publickeys 1006 and a second set of public keys 1008.

The recipient extracts a message body 1010 from the signed message anduses a cryptographic hash function to determine an n-bit message hash1012 for the message body 1010. For each bit (m) of the n-bit messagehash 1012, the recipient determines whether the bit is a one or zero. Ifthe bit is a zero, the recipient compares the m'th key of the first setof public keys 1006 to the m'th hash of the hash sequence 1004. If thebit is a one, the recipient compares the m'th key of the second set ofpublic keys 1008 to the m'th hash of the hash sequence 1004. If any ofthe comparisons do not match, the signature is not valid for theprovided message. If the comparisons match, the signature is valid. Insome implementations, additional verifications are performed to confirmthat the public keys provided are in compliance with a Merkle tree orhash tree maintained by a signature authority. For each bit of the n-bitmessage hash 1012, a public key is chosen from either the first set ofpublic keys 1006 or the second set of public keys 1008. For ‘zero’ bitsof the n-bit message hash 1012, a public key corresponding to the bit inthe n-bit message hash is selected from the first set of public keys1006. For ‘one’ bits of the n-bit message hash 1012, a public keycorresponding to the bit in the n-bit message hash 1012 is selected fromthe second set of public keys 1008. The bit position within the n-bitmessage hash 1012 corresponds to the row (key number) within either thefirst set of public keys 1006 or second set of public keys 1008. In theexample shown in FIG. 10 , for each bit of the n-bit message hash, anarrow indicates the row of the particular public key (having n-bits)that is compared to the hash sequence 1004.

FIG. 11 shows an illustrative example of a secret key with an associatedpublic key. A diagram 1100 shows a one-time-use cryptographic key 1102.The one-time-use cryptographic key 1102 comprises a secret key portion1106 and a public key portion 1108 that is cryptographically derivedfrom the secret key portion 1106 using a hash function 1110 such as acryptographic hash or one-way function. In some examples, the public keyportion is cryptographically derived from the secret key portion using ahash function such as a cryptographic hash or one-way function. Inanother example, the public key portion is cryptographically derivedfrom the secret key portion using encryption. The one-time-usecryptographic key 1102 may be a key used in a Lamport signature scheme,a Winternitz signature scheme, or other one-time-use signature schemeusing public and secret key pairs. In some implementations, theone-time-use cryptographic key 1102 is arranged in a hash tree, Merkletree, or other structure where the public key portion 1108 is hashedwith other public key portions of other one-time-use cryptographic keysinto a single public key of a signature entity. In the followingfigures, the combination of the public key portion 1108 and the secretkey portion 1106 may be represented as a public key/secret key pair.

FIG. 12 shows an illustrative example of a Merkle tree of one-time-usecryptographic keys. A diagram 1200 shows a binary Merkle tree that linksa collection of one-time-use cryptographic keys 1202, 1204, 1206, 1208,1210, 1212, 1214, and 1216 to a public key 1217 associated with asignature authority. Each one-time-use cryptographic key is comprised ofa secret key and a public key cryptographically derived from the secretkey using a cryptographic hash. In some examples, the secret keyconsists of n-pairs of n-bit secret keys, and the public key consists ofn-pairs of n-bit hashes that correspond to the n-bit secret keys. Thepublic keys are published by the signature authority, and the secretkeys are maintained by the signature authority for use in generatingdigital signatures. A collection of corresponding level-0 hash nodes1218, 1220, 1222, 1224, 1226, 1228, 1230, and 1232 is generated from thepublic keys of the one-time-use cryptographic keys. In some examples,each level-0 hash node is generated by taking a cryptographic hash of apublic key of an associated one-time-use cryptographic key.

The level-0 hash nodes are incorporated into the Merkle tree. Pairs oflevel-0 hash nodes are combined using a cryptographic hash function togenerate a set of four level-1 hash nodes 1234, 1236, 1238, and 1240. Inthe example shown in FIG. 12 , hash 0,0 and hash 0,1 are concatenatedand hashed to generate hash 1,0. Hash 0,2 and hash 0,3 are concatenatedand hashed to generate hash 1,1. Hash 0,4 and hash 0,5 are concatenatedand hashed to generate hash 1,2. Hash 0,6 and hash 0,7 are concatenatedand hashed to generate hash 1,3. The four level-1 hash nodes arecombined to generate two level-2 hash nodes 1242 and 1244. In theexample shown in FIG. 12 , hash 1,0 and hash 1,1 are concatenated andhashed to generate hash 2,0, and hash 1,2 and hash 1,3 are concatenatedand hashed to generate hash 2,1. The level-2 hash nodes 1242 and 1244are combined and hashed to produce the public key 1217. The public key1217 is published by the signature authority so that recipients of adigital signature are able to confirm that the signature was generatedwith a one-time-use cryptographic key that is linked to the Merkle tree.

A recipient of a digital signature validates the signature using thepublic key information associated with the one-time-use cryptographickey used to generate the digital signature. The public key informationis validated against the public key 1217 that is associated with asignature authority. The signature authority provides the recipient ofthe digital signature with the hash value nodes of the Merkle tree thatare necessary to re-create the public key 1217 from the public keyinformation.

For example, if the one-time-use cryptographic key 1206 is used togenerate the digital signature, the public key information associatedwith the one-time-use cryptographic key 1206 is used to confirm that thedigital signature was created from the secret key associated with theone-time-use cryptographic key 1206. The level-0 hash node 1222 can bere-created by the recipient using the public key information associatedwith the one-time-use cryptographic key 1206. In addition to the publickey 1217, the signature authority provides the level-0 hash node 1224,the level-1 hash node 1234, and the level-2 hash node 1244. Therecipient uses the determined level-0 hash node 1222 and the providedlevel-0 hash node 1224 to generate the level-1 hash node 1236. Therecipient uses the generated level-1 hash node 1236 and the providedlevel-1 hash node 1234 to generate the level-2 hash node 1242. Thegenerated level-2 hash node 1242 and the provided level-2 hash node 1244are used to generate the public key 1217. If the generated public keymatches the published public key provided by the signature authority,the one-time-use cryptographic key 1206 is a valid member of the Merkletree. If the generated public key does not match the published publickey, the one-time-use cryptographic key 1206 is not a valid member ofthe Merkle tree.

FIG. 13 shows an illustrative example of a number of linked Merkle treesthat implement a cryptographic signature scheme for signingattestations. A diagram 1300 shows a cryptographic signature scheme forsigning attestations. A set of one-time-use cryptographic keys 1302,1304, 1306, and 1308 is provided to a host computer system. The set ofone-time-use cryptographic keys is arranged in a Merkle tree. A firstone-time-use cryptographic key 1302 and a second one-time-usecryptographic key 1304 are combined and hashed to generate a firstintermediate hash 1310. A third one-time-use cryptographic key 1306 andthe second one-time-use cryptographic key 1308 are combined and hashedto generate a second intermediate hash 1312. The first intermediate hash1310 and the second intermediate hash 1312 are combined and hashed togenerate a host root hash 1314.

The host root hash 1314 and other host root hashes generated by otherhost computer systems are provided to a service provider and integratedinto a service-provider hash tree. Hashes of the host computer systemsincluding the host root hash 1314 are combined and hashed to generate afirst service-provider intermediate hash 1316 and a secondservice-provider intermediate hash 1318. The first service-providerintermediate hash 1316 and the second service-provider intermediate hash1318 are combined and hashed to generate a service-provider root key1320. The service-provider root key 1320 is published by the serviceprovider, which enables entities that receive digital signaturesgenerated using the set of one-time-use cryptographic keys 1302, 1304,1306, and 1308 to verify that the digital signatures have been generatedby host computer systems authorized by the service provider.

Host computer systems that generate virtual computing environments suchas virtual machines use one of the set of one-time-use cryptographickeys 1302, 1304, 1306, and 1308 to sign a Merkle tree of one-time-usecryptographic keys provided to each virtual computing environmentmanaged by the host computer system. In some examples, the host computersystem generates a Merkle tree of one-time-use cryptographic keys forthe virtual computing environment, and provides the Merkle tree ofone-time use cryptographic keys to the virtual computing environment. Inanother example, the host computer system causes the TPM on the hostcomputer system to generate the Merkle tree of one-time-usecryptographic keys, and provides the virtual computing environment witha credential that allows the virtual computing environment to access theMerkle tree of one-time-use cryptographic keys on the TPM. In yetanother example, the virtual computing environment generates the Merkletree of one-time-use cryptographic keys and provides the root node ofthe Merkle tree of one-time-use cryptographic keys to the host computersystem.

The host computer system, after confirming the validity of the virtualcomputing environment, signs a root node of the Merkle tree 1322 withone of the set of one-time-use cryptographic keys 1302, 1304, 1306 or1308. The root node of the Merkle tree 1322 is published by the virtualcomputing environment. The one-time-use keys 1324 and 1326 may be usedby the virtual computing environment to generate signed attestationswhich may be provided to applications, end users, or other entities.

A recipient of a digital signature generated with one of theone-time-use keys 1324 or 1326 is able to verify the digital signatureagainst the service-provider root key 1320. The recipient first confirmsthat the digital signature is generated with one of the one-time-usecryptographic keys issued to the virtual computing environment byregenerating the hashes from the particular key to the root node of theMerkle tree 1322. The root node of the Merkle tree 1322 is signed by aone-time-use key controlled by the host computer system hosting thevirtual computing environment. The recipient confirms the hashes betweenthe particular one-time-use cryptographic key of the host computersystem to the host root hash 1314. The Merkle tree controlled by theservice provider links to the host root hash, so the recipient is ableto continue to confirm hashes up to the service-provider root key 1320.

FIG. 14 shows an illustrative example of an environment in which variousembodiments may be practiced. A system diagram 1400 shows a signatureauthority 1402 that maintains a database of one-time-use keys 1404. Thesignature authority 1402 is a computer server, server cluster, virtualcomputer system, or other computing appliance configured with one ormore services that generate and manage the one-time-use keys. Uponinitialization, the signature authority 1402 generates a set ofone-time-use keys. The set of one-time-use keys is of a finite fixedsize. Each one-time-use key may be used to generate a digital signature.If a one-time-use key is used more than once, the cryptographic strengthof the resulting digital signature is reduced with each additional use.Therefore, in some implementations, the signature authority 1402maintains a record of key use to track or prevent the reuse ofindividual cryptographic keys.

The signature authority 1402 delegates signature authority to one ormore authorized computer systems by providing a subset of theone-time-use keys to each authorized computer system. In the exampleshown in FIG. 14 , the signature authority 1402 provides the first keyset to a first authorized signing delegate 1406, a second key set to asecond authorized signing delegate 1408, and a third key set to a thirdauthorized signing delegate 1410. The signature authority 1402 providesthe first authorized signing delegate 1406, the second authorizedsigning delegate 1408, and the third authorized signing delegate 1410with non-overlapping subsets of the one-time-use keys. The signatureauthority 1402 maintains a record of the key subsets delegated. Thesignature authority 1402 may provide additional information such as keyhashes, public keys, and revocation hashes to support the generation ofdigital signatures by the authorized signing delegates.

The number of cryptographic keys provided to each authorized signingdelegate may be based on a predicted number of digital signatures to begenerated by each of delegate. In some implementations, the signatureauthority 1402 predicts the number of digital signatures to be generatedby each authorized delegate, and provides an appropriate number ofcryptographic keys. In another implementation, each delegate requests aparticular number of cryptographic keys based on a number of digitalsignatures predicted by the delegate. In some implementations, if aparticular delegate runs out of cryptographic keys, the delegate mayrequest and receive additional keys from the signature authority 1402.In another implementation, unused cryptographic keys may be returnedfrom a delegate to the signature authority 1402.

In some implementations, the signature authority 1402 generates a set ofsecret revocation values and revocation hashes when the one-time-usekeys are generated, and integrates the revocation hashes into a hashtree of the one-time-use keys. When a particular one-time-use key isrevoked, the signature authority 1402 records the revocation in thedatabase of one-time-use keys 1404, and publishes a secret revocationvalue associated with the revoked one-time-use key as proof of thesignature authority's control over the one-time-use key.

FIG. 15 shows an illustrative example of a one-time-use cryptographickey that includes secret key pairs and corresponding public key pairs. Adiagram 1500 shows a one-time-use key that is generated by a signatureauthority. The one-time-use key is comprised of a secret key pair 1502and a public key pair 1504. The secret key pair 1502 includes a firstsecret key 1506 and a second secret key 1508. The first secret key 1506and the second secret key 1508 each consist of a number (n) of n-bitkeys. In some implementations, the first secret key 1506 and the secondsecret key 1508 are random numbers generated by the signature authority.In other implementations, the signature authority generates the firstsecret key 1506 and the second secret key 1508 from a secret seed valueusing a key derivation function (“KDF”). In some implementations, thesecret seed value is itself generated from another secret seed valuemanaged by the signature authority or owned by a superior signatureauthority.

The public key pair 1504 includes a first public key 1510 and a secondpublic key 1512. The first public key 1510 and the second public key1512 each include a number (n) of n-bit hashes that correspond to thekeys of the first secret key 1506 and the second secret key 1508. Eachn-bit key of the secret key pair 1502 is used to generate acorresponding n-bit hash of the public key pair 1504. For example, thehash of the first key of the first secret key 1506 is the first hash ofthe first public key 1510. Each hash is generated with a cryptographichash function or one-way function h(x)=y where y is easy to calculatefor a given x, but x is computationally difficult to calculate for agiven y. In some examples, SHA256, MD5, BLAKE, or BLAKE2 hash functionsare used to generate the hashes. The public key pair 1504 is publishedby the signature authority.

FIG. 16 shows an illustrative example of signing a message with aone-time-use cryptographic key. A diagram 1600 illustrates the signingof a message 1602 by a signature authority using a one-time-use key. Invarious examples, the message 1602 may be a network packet, digitalcertificate, transactional record, media file, legal document, or othermessage submitted for signing by a requester. The signature authorityreceives the message 1602 from the requester and determines an n-bitmessage hash 1604 using a cryptographic hash function or other one-wayfunction. A one-way function or cryptographic hash has the property thatfor a given input, a hash value is relatively easy to calculate, but fora given hash value, an input that produces the given hash value iscomparatively difficult. In various examples, cryptographic hashfunctions such as SHA-256, MD-5, or BLAKE may be used as thecryptographic hash function.

To sign the message 1602, the signature authority selects a one-time-usekey for use in generating the digital signature. In some examples, ifthe signature authority has exhausted the supply of one-time-use keys,the signature authority reports an error and does not sign the message1602. In other examples, if the signature authority has used the supplyof one-time-use keys, a key may be selected for reuse. A particularcryptographic key may be selected for reuse based at least in part onthe number of times the particular key has been reused and theparticular secret keys used to generate previous signatures. In someimplementations, the signature authority maintains a key-use databasethat records the number of times each key has been used, and the digitalsignature generated with each key. In some examples, to locate a key forreuse, the signature authority may locate those keys that have been usedthe least number of times to generate digital signatures. In anotherexample, the signature authority is provided with the message to besigned, and the signature authority identifies a cryptographic key forreuse that, when generating a digital signature for the message, revealsthe lowest number of additional secret key portions of the availablereusable cryptographic keys.

The one-time-use key includes a secret key pair that includes a firstsecret key 1606 and a second secret key 1608. For each bit (m) of then-bit message hash 1604, the signature authority selects either the m'thkey from the first secret key if the bit is a zero bit, or the m'th keyfrom the second secret key if the bit is a one bit. The selected keysare concatenated to form a digital signature 1610 having n-squared bits.The digital signature 1610 is provided to the requester. In addition tothe digital signature 1610, the requester is provided with public keyinformation associated with the selected one-time-use key to support theverification of the digital signature 1610. The public key informationmay include one or more hashes of a hash tree or Merkle tree that linkthe public key information to a public key of the signature authority.For each bit of the n-bit message hash 1604, a secret key is chosen fromeither the first secret key 1606 or the second secret key. For ‘zero’bits of the n-bit message hash 1604, a secret key corresponding to thebit in the n-bit message hash is selected from the first secret key1606. For ‘one’ bits of the n-bit message hash 1604, a secret keycorresponding to the bit in the n-bit message hash is selected from thesecond secret key 1608. The bit position within the n-bit message hash1604 corresponds to the row (key number) within either the first secretkey 1606 or second secret key 1608. In the example shown in FIG. 16 ,for each bit of the n-bit message hash, an arrow indicates the row ofthe particular secret key (having n-bits) which is added to theresulting digital signature 1610.

FIG. 17 shows an illustrative example of verifying a message with aone-time-use cryptographic key. A diagram 1700 illustrates how arecipient of a signed message is able to verify a digital signature. Toverify the signed message, the recipient separates a digital signature1702 from the signed message. The digital signature 1702 has n-squaredbits, and the recipient divides the digital signature 1702 into n-keyportions of n-bits each. The recipient determines a hash of each keyportion and assembles the hashes into a hash sequence 1704 of n, n-bithashes.

Using information provided with the digital signature, the recipientidentifies the particular one-time-use-key used to generate the digitalsignature and requests related public key information from a signatureauthority. The signature authority provides the recipient with a publickey pair corresponding to the one-time-use key used to generate thedigital signature. The public key pair includes a first set of publickeys 1706 and a second set of public keys 1708.

The recipient extracts a message body 1710 from the signed message anduses a cryptographic hash function to determine an n-bit message hash1712 for the message body 1710. For each bit (m) of the n-bit messagehash 1712, the recipient determines whether the bit is a one or zero. Ifthe bit is a zero, the recipient compares the m'th key of the first setof public keys 1706 to the m'th hash of the hash sequence 1704. If thebit is a one, the recipient compares the m'th key of the second set ofpublic keys 1708 to the m'th hash of the hash sequence 1704. If any ofthe comparisons do not match, the signature is not valid for theprovided message. If the comparisons match, the signature is valid. Insome implementations, additional verifications are performed to confirmthat the public keys provided are in compliance with a Merkle tree orhash tree maintained by a signature authority. For each bit of the n-bitmessage hash 1712, a public key is chosen from either the first set ofpublic keys 1706 or the second set of public keys 1708. For ‘zero’ bitsof the n-bit message hash 1712, a public key corresponding to the bit inthe n-bit message hash is selected from the first set of public keys1706. For ‘one’ bits of the n-bit message hash 1712, a public keycorresponding to the bit in the n-bit message hash 1712 is selected fromthe second set of public keys 1708. The bit position within the n-bitmessage hash 1712 corresponds to the row (key number) within either thefirst set of public keys 1706 or second set of public keys 1708. In theexample shown in FIG. 17 , for each bit of the n-bit message hash, anarrow indicates the row of the particular public key (having n-bits)that is compared to the hash sequence 1704.

FIG. 18 shows an illustrative example of a secret key with an associatedpublic key and a revocation key with an associated revocation hashvalue. A diagram 1800 shows a one-time-use cryptographic key 1802 and aone-time-use revocation value 1804. The one-time-use cryptographic key1802 comprises a secret key portion 1806 and a public key portion 1808that is cryptographically derived from the secret key portion 1806.Cryptographically derived from a value means using a one-way function atleast once using inputs that are the values or derived from the values(possibly cryptographically derived from the values). In some examples,the public key portion 1808 is cryptographically derived from the secretkey portion using a hash function 1810 such as a cryptographic hash orone-way function. In another example, the public key portion 1808 iscryptographically derived from the secret key portion using encryption.An encryption operation may be one-way to entities that do not have acorresponding decryption key. The one-time-use cryptographic key 1802may be a key used in a Lamport signature scheme, a Winternitz signaturescheme, or other one-time-use signature scheme using public and secretkey pairs. In some implementations, the one-time-use cryptographic key1802 is arranged in a hash tree, Merkle tree, or other structure wherethe public key portion 1808 is hashed with other public key portions ofother one-time-use cryptographic keys into a single public key of asignature entity.

The one-time-use revocation value 1804 comprises a secret revocationvalue 1812 and a public revocation hash 1814 that is cryptographicallyderived from the secret revocation value 1812. In some examples, thepublic revocation hash 1814 is derived using a hash function 1816 suchas a cryptographic hash or other one-way function. The hash function1816 may be a cryptographic hash or other one-way function that isdifferent from a hash function 1810 used to derive the public keyportion 1808. In various implementations, the public revocation hash1814 is combined with the public key portion 1808 to generate a hashvalue used to verify the integrity of a digital signature generated withthe one-time-use cryptographic key 1802. A signature authority withcontrol over the one-time-use cryptographic key 1802 may publish thesecret revocation value 1812 as an indication that the one-time-usecryptographic key 1802 has been revoked and is no longer valid.

In the following figures, the combination of the public key portion 1808and the secret key portion 1806 may be represented as a publickey/secret key pair, and the combination of the public revocation hash1814 and the secret revocation value 1812 may be represented as arevocation value/revocation hash pair.

FIG. 19 shows an illustrative example of a secret key with an associatedrevocation key that may be used to revoke the signature authority of thesecret key. A diagram 1900 shows how a one-time-use cryptographic key1902 and an associated revocation pair 1904 may be combined to create arevocable one-time-use cryptographic key. The one-time-use cryptographickey 1902 is comprised of a secret key and a public key cryptographicallyderived from the secret key. The revocation pair 1904 is comprised of arevocation value and a revocation hash cryptographically derived fromthe revocation value. In some examples, the revocation hash is based ona cryptographic hash or one-way function of the revocation value. Thepublic key of the one-time-use cryptographic key 1902 and the revocationhash of the revocation pair 1904 are concatenated and fed to a hashfunction 1906. The hash function 1906 generates a linking hash 1908 forthe combination of the one-time-use cryptographic key 1902 and theassociated revocation pair 1904.

Each one-time-use cryptographic key is maintained by a signatureauthority in a structure as shown in FIG. 19 , and each one-time-usecryptographic key has an associated revocation value. Authority overrevoking a particular cryptographic key is controlled by the revocationvalue. In some examples, the signature authority retains control overthe revocation values and determines whether a particular cryptographickey is revoked. In other examples, the signature authority delegatescontrol over the revocation process by providing the revocation valuesto a delegated entity. In yet another example, the revocation values andrevocation hashes are generated by a key-revocation authority, and therevocation hashes are provided to a signature authority. The signatureauthority incorporates the revocation hashes into the revocable keyhash. The entity controlling the revocation values authorizes therevocation of one-time-use cryptographic keys by publishing therevocation values of the one-time-use cryptographic keys to be revoked.

A recipient that receives a cryptographic key or a message signed withthe cryptographic key contacts the revocation authority to determinewhether the cryptographic key has been revoked. The revocation authoritymaintains a database of revoked cryptographic keys and indicates to therecipient whether the cryptographic key is revoked. If the cryptographickey is revoked, the revocation authority provides a revocation valueassociated with the cryptographic key as proof that the cryptographickey was revoked by an authorized revocation authority. The recipientconfirms the correctness of the revocation value by determining a hashof the revocation value, and combining the hash of the revocation valueand a public key associated with the cryptographic key. If the hash ofthe combination matches the revocable key hash of the cryptographic key,the revocation value is valid. If the hash of the combinations does notmatch the revocable key hash of the cryptographic key, the revocationvalue is not valid and the key is not revoked.

FIG. 20 shows an illustrative example of a Merkle tree of one-time-usecryptographic keys. A diagram 2000 shows a binary Merkle tree that linksa collection of one-time-use cryptographic keys 2002, 2004, 2006, 2008,2010, 2012, 2014, and 2016 to a public key 2017 associated with asignature authority. Each one-time-use cryptographic key is comprised ofa secret key and a public key derived from the secret key using acryptographic hash. In some examples, the secret key consists of n-pairsof n-bit secret keys, and the public key consists of n-pairs of n-bithashes that correspond to the n-bit secret keys. The public keys arepublished by the signature authority, and the secret keys are maintainedby the signature authority for use in generating digital signatures. Acollection of corresponding level-0 hash nodes 2018, 2020, 2022, 2024,2026, 2028, 2030, and 2032 are generated from the public keys of theone-time-use cryptographic keys. In some examples, each level-0 hashnode is generated by taking a cryptographic hash of a public key of anassociated one-time-use cryptographic key.

The level-0 hash nodes are incorporated into the Merkle tree. Pairs oflevel-0 hash nodes are combined using a cryptographic hash function togenerate a set of four level-1 hash nodes 2034, 2036, 2038, and 2040. Inthe example shown in FIG. 20 , hash 0,0 and hash 0,1 are concatenatedand hashed to generate hash 1,0. Hash 0,2 and hash 0,3 are concatenatedand hashed to generate hash 1,1. Hash 0,4 and hash 0,5 are concatenatedand hashed to generate hash 1,2. Hash 0,6 and hash 0,7 are concatenatedand hashed to generate hash 1,3. The four level-1 hash nodes arecombined to generate two level-2 hash nodes 2042 and 2044. In theexample shown in FIG. 20 , hash 1,0 and hash 1,1 are concatenated andhashed to generate hash 2,0, and hash 1,2 and hash 1,3 are concatenatedand hashed to generate hash 2,1. The level-2 hash nodes 2042 and 2044are combined and hashed to produce the public key 2017. The public key2017 is published by the signature authority so that recipients of adigital signature are able to confirm that the signature was generatedwith a one-time-use cryptographic key that is linked to the Merkle tree.

A recipient of a digital signature validates the signature using thepublic key information associated with the one-time-use cryptographickey used to generate the digital signature. The public key informationis validated against the public key 2017 that is associated with asignature authority. The signature authority provides the recipient ofthe digital signature with the hash value nodes of the Merkle tree thatare necessary to re-create the public key 2017 from the public keyinformation.

For example, if the one-time-use cryptographic key 2006 is used togenerate the digital signature, the public key information associatedwith the one-time-use cryptographic key 2006 is used to confirm that thedigital signature was created from the secret key associated with theone-time-use cryptographic key 2006. The level-0 hash node 2022 can bere-created by the recipient using the public key information associatedwith the one-time-use cryptographic key 2006. In addition to the publickey 2017, the signature authority provides the level-0 hash node 2024,the level-1 hash node 2034, and the level-2 hash node 2044. Therecipient uses the determined level-0 hash node 2022 and the providedlevel-0 hash node 2024 to generate the level-1 hash node 2036. Therecipient uses the generated level-1 hash node 2036 and the providedlevel-1 hash node 2034 to generate the level-2 hash node 2042. Thegenerated level-2 hash node 2042 and the provided level-2 hash node 2044are used to generate the public key 2017. If the generated public keymatches the published public key provided by the signature authority,the one-time-use cryptographic key 2006 is a valid member of the Merkletree. If the generated public key does not match the published publickey, the one-time-use cryptographic key 2006 is not a valid member ofthe Merkle tree.

FIG. 21 shows an illustrative example of a Merkle tree of one-time-usecryptographic keys that includes revocation keys for revoking portionsof the tree. A diagram 2100 shows a Merkle tree of one-time-usecryptographic keys that includes revocation nodes for the internal nodesof the tree. The Merkle tree links a collection of one-time-usecryptographic keys 2102, 2104, 2106, 2108, 2110, 2112, 2114, and 2116 toa public key 2117 associated with a signature authority. Eachone-time-use cryptographic key includes a secret key and a public keythat is generated from the secret key using a cryptographic hash. Valuesassociated with the various internal nodes of the Merkle tree arecreated by combining the values associated with the child nodes of theparticular internal node, and determining a cryptographic hash of thecombined value. In some implementations, the values associated with thechild nodes are combined by concatenating the values associated with thevarious child nodes and determining a cryptographic hash of theconcatenated value.

A set of eight level-0 hash nodes 2118, 2120, 2122, 2124, 2126, 2128,2130, and 2132 is combined with four level-0 revocation pairs 2148,2150, 2152, and 2154 to produce four level-1 hash nodes 2134, 2136,2138, and 2140. Each revocation pair includes a revocation value and arevocation hash that is based on the revocation value. In the exampleshown in FIG. 21 , the level-0 hash node 2118 and the level-0 hash node2120 are combined with the revocation hash of revocation pair 2148 toproduce the level-1 hash node 2134. The level-0 hash node 2122 and thelevel-0 hash node 2124 are combined with the revocation hash ofrevocation pair 2150 to produce the level-1 hash node 2136. The level-0hash node 2126 and the level-0 hash node 2128 are combined with therevocation hash of revocation pair 2152 to produce the level-1 hash node2138. The level-0 hash node 2130 and the level-0 hash node 2132 arecombined with the revocation hash of revocation pair 2154 to produce thelevel-1 hash node 2140.

The set of four level-1 hash nodes 2134, 2136, 2138, and 2140 iscombined with the revocation hashes of two level-1 revocation pairs 2156and 2158 to produce two level-2 hash nodes 2142 and 2144. The level-1hash node 2134 and the level-1 hash node 2136 are combined with therevocation hash of the level-1 revocation pair 2156 to produce thelevel-2 hash node 2142. The level-1 hash node 2138 and the level-1 hashnode 2140 are combined with the revocation hash of the level-1revocation pair 2158 to produce the level-2 hash node 2144. The twolevel-2 hash nodes 2142 and 2144 are combined with the level-2revocation pair 2160 to produce the public key 2117.

The signature authority is able to use the revocation pairs to indicaterevocation of a set of one-time-use cryptographic keys that aresubordinate to a particular node of the Merkle tree by publishing therevocation value associated with the particular node. For example, bypublishing the revocation value associated with the revocation pair2150, the signature authority proves the revocation of the one-time-usecryptographic keys 2106 and 2108. In another example, the signatureauthority is able to revoke the one-time-use cryptographic keys 2110,2112, 2114, and 2116 by publishing the revocation value associated withthe revocation pair 2158.

In some implementations, each one-time-use cryptographic key shown inFIG. 21 is replaced with a structure that includes a correspondingrevocation value as shown in FIG. 19 , and the level-0 hashes arereplaced with revocable one-time-use key hashes as shown in FIG. 19 . Insuch implementations, the revocation authority may revoke an individualone-time-use cryptographic key by publishing the revocation valueassociated with the individual one-time-use cryptographic key.

In some implementations, the revocation pairs may be generated by arevocation authority other than the signature authority, and therevocation hashes are provided to the signature authority for inclusionin the Merkle tree. Particular one-time-use cryptographic keys arerevoked by the revocation authority publishing one or more revocationvalues.

FIG. 22 shows an illustrative example of a set of seed values that areused to generate a set of one-time-use keys and corresponding publickeys. A diagram 2200 illustrates a process whereby one or more seedvalues 2202 are used to generate a number of secret keys 2204. Acorresponding collection of public keys 2206 is generated from thesecret keys 2204 using a cryptographic hash function. In some examples,the one or more seed values 2202 is a single seed value that generates aplurality of secret keys. In another example, the one or more seedvalues 2202 is a plurality of seed values, each of which generates oneor more secret keys. In yet another example, the one or more seed values2202 is a plurality of related seed values, and each seed valuegenerates a set of secret keys. For example, a master seed value may beused to generate a number of subordinate seed values, and eachsubordinate seed value is used to generate a subset of secret keys. Anoriginal seed value may be used to generate another seed value byapplying a cryptographic hash or one-way function to the original seedvalue.

The secret keys 2204 are generated from the seed values 2202. Any numberof secret keys may be generated from a single seed value. In someexamples, the secret keys 2204 are generated using a key derivationfunction, key stretching algorithm, key strengthening algorithm, orcryptographic hash. In another example, the secret keys 2204 aregenerated using linear feedback shift register or pseudo-random numbergeneration algorithm using the seed value as an initializer. The publickeys 2206 are generated from the secret keys 2204 using a cryptographichash or one-way function in accordance with the type of one-time-usecryptographic key desired by generating the one-time-use cryptographickeys from a set of seed values, and the seed values may be used as ashorthand to distribute subsets of the one-time-use cryptographic keysto delegate signature authorities.

FIG. 23 shows an illustrative example of a set of one-time-usecryptographic keys that are generated from a tree of seed values. Adiagram 2300 illustrates a tree structure containing a collection ofrelated seed values that are used to generate a collection of secretkeys. The tree structure may be generated by a signature entity or otherentity that is responsible for generating a collection of one-time-usecryptographic keys. A master seed 2302 controls the generation of theremaining seeds and the secret keys. The master seed 2302 is randomlygenerated by the signature entity. Each of the subordinate nodes of themaster seed 2302 is generated by applying a one-way function orcryptographic hash to the value of the parent node, an optional saltvalue, and an index. For example, two child seed values are generatedfrom the master seed 2302. Using a published cryptographic hashfunction, an optional salt value, and a node index, the signatureauthority generates a first level-2 seed 2304 (index-1) and a secondlevel-2 seed 1006 (index=2). Each of the level-2 seed values is used togenerate two additional subordinate seed values using the one-wayfunction or cryptographic hash. The first level-2 seed 2304 is used togenerate a first level-1 seed 2308 and a second level-1 seed 2310, andthe second level-2 seed 2306 is used to generate a third level-1 seed2312 and a fourth level-1 seed 2314.

The level-1 seed values are used to generate a collection of secret keysassociated with one-time-use keys. The secret keys are derived from thelevel-1 seed values using a combination of a cryptographic hash and akey derivation function. The use of a cryptographic hash prevents theholder of a secret key from deriving the seed value used to generate thesecret key and therefore prevents access to other secret keys derivedfrom the same seed value. The key derivation function produces an outputin a format that is appropriate for use as a secret key. In the exampleshown in FIG. 23 , each level-1 seed value is used to generate twosecret keys. The first level-1 seed 2308 is used to generate a firstsecret key 2316 and a second secret key 2318. The second level-1 seed2310 is used to generate a first secret key 2320 and a second secret key2322. The third level-1 seed 2312 is used to generate a first secret key2324 and a second secret key 2326. The fourth level-1 seed 2314 is usedto generate a first secret key 2328 and a second secret key 2330.

In many examples, the secret keys are used as the basis to create acollection of one-time-use cryptographic keys. The signature authorityhashes the secret keys to produce a complementary set of public keyswhich are arranged in a Merkle tree. The Merkle tree may have astructure similar to the structure of the seeds used to produce thesecret keys. Groups of one-time-use keys may be delegated to asubordinate signature authority by providing a seed value correspondingto a common parent node of the one-time-use keys to be delegated. Usingthe seed value, the subordinate signature authority may regenerate thesecret keys for the corresponding nodes of the Merkle tree.

In other implementations, the structure of the tree used to organize theseed values is different from the structure of the Merkle tree. In someexamples the tree of seed values may be constructed with a structurethat matches an organizational structure, with the master seed beingcontrolled by a central corporate authority, and internal nodes of theseed tree representing particular departments within the corporation. Inother examples, the tree of seed values may be arranged in accordancewith a hierarchy of potential signature delegates. In someimplementations, the structure of the seed-value tree includes a rootseed and an internal layer of seed nodes that can be delegated to one ormore signature delegates. Each internal seed node is used to generate anumber of secret keys that can be delegated as a unit. Regardless of thestructure of the seed-value tree, the resulting secret keys are used togenerate a corresponding set of public keys, and the public keys arehashed and linked to a Merkle tree.

FIG. 24 shows an illustrative example of a process that, as a result ofbeing performed by a signature authority, generates a seed tree thatsupports delegation of one-time-use cryptographic keys. A flowchart 2400illustrates a process that begins at block 2402 with the signatureauthority generating a master seed value. The master seed value is arandom number and may be generated using hardware or software based onrandom number generation techniques. The master seed value is placed ina tree-node record allocated in memory by the signature authority. Eachtree-node record includes one or more pointers that reference childnodes.

After generating the master seed value, the signature authoritycontinues constructing the seed tree at block 2404. At block 2404, thesignature authority initiates a loop that iterates over each level ofthe desired seed tree starting at the top with the master seed valuenode and ending one level above the leaf nodes. Within the above loop,at block 2406, the signature authority iterates over each tree-node atthe iterated level. At block 2408, the signature authority generateschild nodes for each iterated tree node. For each tree node, thesignature authority allocates new child nodes in memory and setspointers from the iterated tree node to each of the new child nodes. Thesignature authority generates a value for each new child node that isdetermined based on a function of the seed value of the iterated treenode and the position of the new child node. In some examples, the valueof each new child node is determined by a function that takes the valueof the seed of the parent node, the level of the parent node, theposition of the parent node within the level, and the number of childnodes associated with the parent. The function by which the seed valuesof new child nodes are determined is a one-way function or cryptographichash that prevents the derivation of parent seed values from child seedvalues.

At decision block 2410, the signature authority determines whether thereare additional nodes at the currently iterated tree level. If there areadditional nodes in the currently iterated tree level, execution returnsto block 2406 and new child nodes for the next node in the iterated treelevel are created. If there are not additional nodes in the currentlyiterated tree level, execution advances to decision block 2412. Atdecision block 2412, the signature authority determines whether thereare additional levels of the seed tree to be processed. If there areadditional levels of the seed tree to be processed, execution returns toblock 2404 and the next level of the seed tree is processed. If thereare not additional levels of the seed tree to be processed, executionadvances to block 2414.

At block 2414, the signature authority generates secret keys from thelowest level of the seed tree. In some examples, the signature authoritygenerates a single secret key from each seed node at the bottom of theseed tree. In another example, the signature authority generates anumber of secret keys from each seed node at the bottom of the seedtree. In some examples, the secret keys are generated using acombination of a one-way function or cryptographic hash and a keyderivation function so that the secret keys may not be used to easilyderive the seed value. In another example, the secret keys are generatedusing a key derivation function that uses the seed value as input.

FIG. 25 shows an illustrative example of a process that, as a result ofbeing performed by a signature authority, delegates a portion ofone-time-use cryptographic keys to an authorized entity. A flowchart2500 illustrates a process that begins at block 2502 with a signatureauthority receiving a request from a prospective delegate to generatedigital signatures on behalf of the signature authority. To generate thedigital signatures, the prospective delegate requests a number ofone-time-use keys from the signature authority. The perspective delegatemay be a server, server cluster, or other computing entity operated by abusiness, department, or subsidiary of the signature authority. Thesignature authority authenticates the identity of the prospectivedelegate using a combination of digital certificates, biometricmeasures, or multiply-factor authentication techniques. Afterauthenticating the prospective delegate, the signature authority mayconsult an authorization database to confirm that the prospectivedelegate is authorized to generate signatures on behalf of the signatureauthority. If the prospective delegate is authorized to generatesignatures on behalf of the signature authority, execution advances todecision block 2504.

At decision block 2504, the signature authority examines a store ofone-time-use keys that are maintained by the signature authority forgenerating digital signatures. The store includes information thatdescribes which of the one-time-use keys have been previously used togenerate digital signatures. If the number of one-time-use keysrequested by the prospective delegate is greater than the number ofone-time-use keys that have not yet been used to generate a digitalsignature, execution advances to block 2506 and the signature authoritygenerates an error. At block 2506, the signature authority indicates tothe prospective delegate that there are insufficient one-time-use keysavailable to satisfy the request, and the request is denied.

If there are sufficient one-time-use keys available to satisfy therequest, execution advances to block 2508. At block 2508, the signatureauthority identifies one or more seed values that can be used todelegate an appropriate set of secret keys to the prospective delegate.The one or more seed values are selected so that the children of the oneor more seed values represent the number of secret keys requested. Forexample, if the prospective delegate requests four one-time-use keys,the signature authority will identify a seed value that can be used togenerate four previously unused one-time-use keys. For example, in FIG.23 , the seed 2306 may be provided since it may be used to generate thefour secret keys 2324, 2326, 2328, and 2330. In some examples, a numberof seed values may be provided. If the prospective delegate requests sixsecret keys, the signature authority may provide a first seed value thatcan be used to generate two previously unused one-time-use keys, and asecond seed value that can be used to generate four previously unusedone-time-use keys.

At block 2510, the signature authority identifies a set of intermediatehashes that will allow the prospective delegate to verify signaturesgenerated with the identified seed values. In some implementations, thestructure of the seed tree matches the structure of a Merkle tree thatis associated with the one-time-use keys. The signature authorityidentifies the interior nodes of the Merkle tree that correspond to theseed values to be delegated to the prospective delegate. For eachidentified interior node of the Merkle tree, the signature authorityidentifies hash nodes between the identified interior node and the rootof the Merkle tree that are used to verify digital signaturessubordinate to the identified interior node. If more than one seed valueis delegated to the prospective delegate, a corresponding number ofhash-node sets are identified to allow the prospective delegate toverify digital signatures.

At block 2512, the signature authority provides the seed values to bedelegated, the positions of the seed values within the Merkle tree, andthe hash-node sets to the prospective delegate. The delegate uses theseed values to generate a set of secret keys and corresponding publickey pairs that are usable as one-time-use keys. The one-time-use keysmay be used to generate digital signatures, and the digital signaturesmay be verified using the Merkle tree by confirming the hashes of thepublic key pairs against the root of the Merkle tree which is owned bythe signature authority.

FIG. 26 shows an illustrative example of a process that, as a result ofbeing performed by an authorized signature delegate, signs a messageusing a one-time-use cryptographic key provided by a signatureauthority. A flowchart 2600 illustrates a process that begins at block2602 with a delegate receiving a request to sign a message from arequester. The delegate has a set of seed values and supportinginformation that are usable to generate a set of one-time-usecryptographic keys that are verifiable against the public key owned bythe signature authority. The delegate authenticates the requester andconfirms that the request is authorized. If the signature request isauthorized, execution advances to decision block 2604.

At decision block 2604, the delegate determines whether the delegate hasan unused one-time-use cryptographic key with which to generate adigital signature. If the delegate does not have an unused one-time-usecryptographic key, execution advances to block 2606. At block 2606, thedelegate generates an error and indicates to the requester thatinsufficient signing keys are available. In some implementations, thedelegate requests additional one-time-use cryptographic keys from thesignature authority. In yet another implementation, the delegateidentifies a one-time-use cryptographic key from the set of one-time-usecryptographic keys previously allocated to the delegate for reuse. Insome implementations, the delegate maintains a first counter of keysallocated by the signature authority, and a second counter of keys usedto generate digital signatures in order to identify when unused keys areavailable. If at least one one-time-use cryptographic key is available,execution advances to block 2608.

At block 2608, the delegate uses the seed values allocated to thedelegate by the signature authority to generate a set of secret keys. Insome implementations, the delegate generates a complete set of secretkeys from the seed values allocated to the delegate and stores the setof secret keys in a data store to be used as needed. The delegate trackswhich secret keys have been previously used to generate digitalsignatures, and selects a particular set of secret keys that have notyet been used to generate the requested digital signature. Afterselecting the particular set of secret keys, the signature authoritydetermines 2610 a hash value for the message to be signed, and uses thehash value and the generated set of secret keys to generate a signaturefor the message. In some examples, the signature is generated inaccordance with the process shown and described in FIG. 16 . Aftergenerating the signature, delegate records that the one-time-used keyassociated with the particular set of secret keys has been used.

At block 2612, the delegate uses the set of secret keys to generate acorresponding set of public keys to be used in verifying the signature.The public keys may be generated by determining a cryptographic hash ofeach secret key in the set of secret keys as described in FIG. 15 . Atblock 2614, the delegate uses the public keys to generate a set ofcryptographic hashes that are arranged in a Merkle tree. The Merkle treegenerated by the delegate connects to a parent Merkle tree maintained bythe signature authority. At block 2616, the delegate retrieves hashinformation from the parent Merkle tree from the signature authoritythat allows the delegate to verify digital signatures generated by thedelegate against a root public key owned by the signature authority. Insome examples, the signature authority provides the hash valuesassociated with the child nodes of each node in the Merkle tree from theroot node to the interior node associated with the each seed valuedelegated to the delegate.

At block 2618, the delegate assembles the signature and the supportinginformation to be provided to the requester. The delegate assembles andprovides the signature of the message, information that identifies theone-time-use key used to sign the message, the public key of theone-time-use key used to sign the message, and the intermediate hashesnecessary to verify the signature against the root hash of the Merkletree maintained by the signature authority. Using the providedinformation, the recipient is able to verify that the signature of themessage matches the public keys of the one-time-use key, and that thepublic keys of the one-time-use key are linked to the Merkle tree and tothe root of the Merkle tree which is maintained by the signatureauthority. Therefore, although the signature is generated and providedby the delegate, it can be validated against the signature authority'spublic key, even though the delegate may not have access to all of theone-time-use keys controlled by the signature authority.

FIG. 27 shows an illustrative example of a delegation service thatallocates and distributes blocks of cryptographic keys to one or moreauthorized delegates. A system diagram 2700 shows a key delegationserver 2702 operated by a signature authority that provides blocks ofone-time-use cryptographic keys to a delegate computer system 2704. Thekey delegation server 2702 is a computer system, computer server orserver cluster that includes a processor and memory. The memory containsinstructions that implement one or more services. The key delegationserver 2702 maintains a Merkle tree of delegable keys 2706 in a memoryon the key delegation server 2702. The delegable keys 2706 areone-time-use cryptographic keys such as Lamport keys or Winternitz keysthat are used to generate digital signatures. The key delegation server2702 includes a key delegation interface 2708, a key publication service2710, and a key delegation service 2712.

The key delegation interface 2708 is a public interface that allowspotential signature delegates to request blocks of one-time-usecryptographic keys from the key delegation server 2702. The keydelegation interface 2708 accesses a delegate database 2714 thatcontains information identifying authorized delegates, and theparticular one-time-use cryptographic keys allocated to particularauthorized delegates. The key delegation interface 2708 includes anauthentication service 2716 and an authorization service 2718. When adelegate contacts the key delegation server 2702, the authenticationservice 2716 within the key delegation interface 2708 confirms theidentity of the delegate using a digital certificate, user-passwordcombination, fingerprint or other biometric. After the delegate has beenauthenticated, the authorization service 2718 queries the delegatedatabase 2714 and determines whether the delegate is authorized togenerate signatures on behalf of the signature authority. Theinformation in the delegate database 2714 may be maintained by anadministrator of the signature authority, and may include restrictionson the number of one-time-use keys that may be assigned to a particulardelegate.

The key publication service 2710 includes a key revocation service 2720and a verification service 2722. The key publication service 2710 isused by entities that generate and verify digital signatures. The keypublication service 2710 accesses the Merkle tree of delegable keys 2706and makes available public keys and hashes that allow a particulardigital signature generated with a one-time-use key to be verified. Forexample, when an entity contacts the key publication service 2710 toverify a digital signature, the verification service 2722 within the keypublication service 2710 queries the Merkle tree of delegable keys 2706to acquire the hashes within the Merkle tree that are necessary toconfirm the link between the digital signature and the public key of thesignature entity.

In some implementations, the key publication service 2710 includes a keyrevocation service 2720. The key revocation service provides informationregarding the revocation of one-time-use cryptographic keys. Whenverifying a digital signature, the verifying entity contacts the keyrevocation service 2720 and queries whether the cryptographic key usedto generate the digital signature is still valid. The key revocationservice 2720 queries the Merkle tree of delegable keys 2706, and if thecryptographic key is marked as invalid, the key revocation service 2720provides the verifying entity with a revocation value associated withthe revoked cryptographic key. The verifying entity confirms thevalidity of the revocation value by hashing the revocation value andcombining the revocation hash with intermediate hashes in the Merkletree to reproduce the public key of the signature authority. In someexamples, the key revocation service 2720 maintains a revocationdatabase that indicates which keys have been revoked. The revocationdatabase may be a relational database, hash table, list. In someimplementations, the revocation database is implemented using ablockchain.

The delegate computer system 2704 may contact the key delegation server2702 to acquire additional blocks of one-time-use cryptographic keys asneeded to generate digital signatures. When the delegate computer system2704 sends a request for keys to the key delegation server 2702, therequest is received by the key delegation interface 2708. The keydelegation interface authenticates the delegate computer system 2704 andauthorizes the request. The request is forwarded to the key delegationservice 2712, and the key delegation service 2712 identifies a set ofone-time-use cryptographic keys from the Merkle tree of delegable keys2706. The set of one-time-use cryptographic keys is marked as beingallocated to the delegate computer system 2704, and the delegatedatabase 2714 is updated to record the keys that are allocated to thedelegate computer system 2704. The key delegation service 2712 returnsthe requested one-time-use cryptographic keys to the delegate computersystem 2704. The key delegation service 2712 provides information to thekey publication service 2710 indicating the additional one-time-usecryptographic keys that are been allocated to the delegate computersystem 2704. Using information from the delegate database 2714, theverification service 2722 identifies the intermediate hashes necessaryto verify digital signatures generated using the additional one-time-usecryptographic keys, and provides the intermediate hashes to the delegatecomputer system 2704. In some implementations, the key publicationservice 2710 identifies verification information that has already beenprovided to the delegate computer system, and provides only theadditional verification information not already in the possession of thedelegate computer system 2704.

FIG. 28 shows an illustrative example of a process that, as a result ofbeing performed by a key distribution service and a delegate, allocatesa block of keys managed by the distribution service to be used by thedelegate. A swim diagram 2800 illustrates a process that begins at block2802 with the delegate estimating a number of digital signatures to begenerated on behalf of the signature authority. The number of digitalsignatures may be estimated based on previous signature generation overa period of time or based on a number of pending messages to be signed.At block 2804, the delegate sends a request specifying the number ofone-time-use keys desired to the distribution service.

At block 2806, the distribution service receives the request from thedelegate and authenticates the delegate using a digital certificate, ausername/password, or other authentication credential. At block 2808,the distribution service determines whether the delegate is authorizedto generate digital signatures on behalf of the signature authority byconsulting a database of authorized delegate information. If thedelegate is authorized to generate digital signatures on behalf of thesignature authority, execution advances to block 2810 and thedistribution service consults a database of one-time-use cryptographickeys to determine whether there are sufficient unused one-time-usecryptographic keys to satisfy the request. If there are not sufficientunused one-time-use cryptographic keys to satisfy the request, thedistribution service responds with an error message to the delegate.Otherwise, the distribution service selects 2812 a set of one-time-usecryptographic keys to be provided to the delegate. The selected set ofkeys may be chosen from a Merkle tree such that the set of keys descendsfrom a common internal node of the Merkle tree. If there is not a commoninternal node of the Merkle tree, the selected set of keys may be chosenso that the set of keys comprises a minimum number of internal nodes ofthe Merkle tree. The selected keys may be provided to the delegate byproviding the secret and private key pairs themselves, or by providingseed values associated with the internal nodes of the Merkle tree thatare parents of the set of keys as described elsewhere in this document.

At block 2814, the distribution service records that the selected keyshave been delegated to the delegate. Delegation of the selected keys maybe recorded as a property within the nodes of the Merkle tree or withina database of delegate information maintained by the signatureauthority. At block 2816, the distribution service identifies supportinginformation necessary for key verification. The supporting informationincludes public keys and hash values from the Merkle tree that are usedto verify digital signatures created with the set of delegated keys. Atblock 2818, the distribution service assembles the set of keys and thesupporting information, and provides the set of keys and the supportinginformation to the delegate. In some implementations, the set of keysare provided by providing the secret and public portions of the keysthemselves. In other implementations, the set of keys are provided byproviding seed values that may be used to generate the secret portionsof the keys to be delegated.

At block 2820, the delegate receives the keys and the supportinginformation from the key distribution service. Using the keys andsupporting information, the delegate is able to sign messages withdigital signatures, and the digital signatures produced are able to beverified against a public key maintained by the signature authority.

FIG. 29 shows an illustrative example of a process that, as a result ofbeing performed by a signature authority and a key generator, generatesa subset of one-time-use keys specified by the signature authority usingan intermediate seed value. A swim diagram 2900 illustrates a processthat begins at block 2902 with a signature authority generating a randomseed value to be used in generating a set of one-time-use cryptographickeys. The random seed value may be generated using a hardware randomnumber generator or with pseudorandom number generation techniques.After generating the random root seed value, the signature authoritydetermines 2904 the parameters of a seed tree. The seed tree contains aset of intermediate seed values that are derived from the root seedvalue. In some examples, the intermediate seed values are derived fromthe root seed value using a cryptographic hash or other one-wayfunction. The generation of the intermediate seed values is governed bya tree-depth parameter and a fanout parameter. The tree-depth parameterand the fanout parameter are based at least in part on the desirednumber of one-time-use cryptographic keys to be generated. In oneexample, the fanout parameter is to and the seed tree is a binary tree,and the depth of the seed tree is selected to provide a number ofone-time-use cryptographic keys greater than or equal to the desirednumber of one-time-use script a graphic keys.

After determining the parameters of the seed tree, the signatureauthority generates 2906 the intermediate seed values. In someimplementations, the intermediate seed values are determined bycalculating a cryptographic hash of the value of the parent node plusthe position of the child node being generated. For example, the firstchild node of a particular seed node is determined by calculating thecryptographic hash of the value of the parent node plus one, and thesecond child node of the particular seed node is determined bycalculating the cryptographic hash of the value of the parent node plustwo. The signature authority distributes 2908 the intermediate seedvalues to one or more authorized key generators. The key generators area service running on a computer system that works in coordination withthe signature authority to distribute the generation of one-time-usecryptographic keys. In some examples, the key generators are also ableto perform digital signatures on behalf of the signature authority. Inother examples, the key generators assist the signature authority bygenerating a portion of the one-time-use cryptographic keys, and supplya root hash for the portion of one-time-use cryptographic keys that eachgenerator produces. In yet another example, the key generators providethe signature authority with the one-time-use cryptographic keys thatare generated in addition to the hash values associated with thegenerated one-time-use cryptographic keys.

At block 2910, the key generator receives the intermediate seed valuefrom the signature authority. In some examples, the signature authorityprovides the key generator with parameters of the subset of the seedtree represented by the intermediate seed value. The parameters mayinclude a fanout and depth of the subset of the seed tree to begenerated by the key generator. In yet another example, the signatureauthority specifies a seed generation algorithm and/or a key-generationalgorithm to be used in generating the subset of the seed tree. The keygenerator generates subordinate seed values from the intermediate seedvalue in accordance with any parameters provided by the signatureauthority.

At block 2912, the key generator generates secret portions ofone-time-use keys from leaf nodes of the subset of the seed treegenerated by the key generator. In some examples, the secret portions ofthe one-time-use keys are generated using a cryptographic hash orone-way function and a key derivation function. The cryptographic hashor one-way function prevents a recipient of the one-time-use key fromderiving the seed value used to generate the key, and the key derivationfunction transforms the resulting pseudorandom number into a formatsuitable for use as a key. In some examples, the secret portions of theone-time-use keys are a collection of key pairs. At block 2914, the keygenerator generates public portions of the one-time-use keys from thesecret portions of the one-time-use keys. In some examples, the publicportions of the one-time-use keys are generated by applying acryptographic hash to the secret portions of the one-time-use keys. Inone implementation, the secret portions of the one-time-use keys arepseudorandom key pairs, and the public portions of the one-time-use keysare corresponding pairs of hashes of each pseudorandom key pair.

At block 2916, the key generator generates a subordinate Merkle tree ofthe public portions of the one-time-use keys. The public portions of theone-time-use keys are hashed to produce a set of corresponding hashes.The corresponding hashes are used as the leaf nodes of the Merkle tree,and the key generator completes the Merkle tree using a tree geometrythat corresponds to the geometry of the subset of the seed treegenerated earlier. After generating the Merkle tree, the key generatorprovides 2918 the root hash of the Merkle tree to the signatureauthority. In some implementations, the key generator provides theentire Merkle tree. In yet another implementation, the key generatorprovides the one-time-use keys generated by the key generator inaddition to the Merkle tree.

At block 2920, the signature authority receives the hashes from the keygenerator. The signature authority uses the root hash provided by thekey generator to complete a master hash tree of one-time-use keys thatare managed by the signature authority. The master hash tree may includeadditional root hashes generated by other subordinate signatureauthorities. In some examples, the signature authority combines thehashes provided by the key generator with hashes provided by other keygenerators to complete a master hash tree for the entire set ofone-time-use keys. In this way, the signature authority may distributethe task of generating one-time-use keys amongst a set of trustedkey-generating entities resulting in faster key generation.

FIG. 30 illustrates aspects of an example environment 3000 forimplementing aspects in accordance with various embodiments. As will beappreciated, although a web-based environment is used for purposes ofexplanation, different environments may be used, as appropriate, toimplement various embodiments. The environment includes an electronicclient device 3002, which can include any appropriate device operable tosend and/or receive requests, messages, or information over anappropriate network 3004 and, in some embodiments, convey informationback to a user of the device. Examples of such client devices includepersonal computers, cell phones, handheld messaging devices, laptopcomputers, tablet computers, set-top boxes, personal data assistants,embedded computer systems, electronic book readers, and the like. Thenetwork can include any appropriate network, including an intranet, theInternet, a cellular network, a local area network, a satellite network,or any other such network and/or combination thereof. Components usedfor such a system can depend at least in part upon the type of networkand/or environment selected. Many protocols and components forcommunicating via such a network are well known and will not bediscussed herein in detail. Communication over the network can beenabled by wired or wireless connections and combinations thereof. Inthis example, the network includes the Internet and/or other publiclyaddressable communications network, as the environment includes a webserver 3006 for receiving requests and serving content in responsethereto, although for other networks an alternative device serving asimilar purpose could be used as would be apparent to one of ordinaryskill in the art.

The illustrative environment includes at least one application server3008 and a data store 3010. It should be understood that there can beseveral application servers, layers, or other elements, processes, orcomponents, which may be chained or otherwise configured, which caninteract to perform tasks such as obtaining data from an appropriatedata store. Servers, as used herein, may be implemented in various ways,such as hardware devices or virtual computer systems. In some contexts,servers may refer to a programming module being executed on a computersystem. As used herein, unless otherwise stated or clear from context,the term “data store” refers to any device or combination of devicescapable of storing, accessing and retrieving data, which may include anycombination and number of data servers, databases, data storage devices,and data storage media, in any standard, distributed, virtual, orclustered environment. The application server can include anyappropriate hardware, software, and firmware for integrating with thedata store as needed to execute aspects of one or more applications forthe client device, handling some or all of the data access and businesslogic for an application. The application server may provide accesscontrol services in cooperation with the data store and is able togenerate content including, but not limited to, text, graphics, audio,video, and/or other content usable to be provided to the user, which maybe served to the user by the web server in the form of HyperText MarkupLanguage (“HTML”), Extensible Markup Language (“XML”), JavaScript,Cascading Style Sheets (“CSS”), JavaScript Object Notation (JSON),and/or another appropriate client-side structured language. Contenttransferred to a client device may be processed by the client device toprovide the content in one or more forms including, but not limited to,forms that are perceptible to the user audibly, visually, and/or throughother senses. The handling of all requests and responses, as well as thedelivery of content between the client device 3002 and the applicationserver 3008, can be handled by the web server using PHP: HypertextPreprocessor (“PHP”), Python, Ruby, Perl, Java, HTML, XML, JSON, and/oranother appropriate server-side structured language in this example.Further, operations described herein as being performed by a singledevice may, unless otherwise clear from context, be performedcollectively by multiple devices, which may form a distributed and/orvirtual system.

The data store 3010 can include several separate data tables, databases,data documents, dynamic data storage schemes and/or other data storagemechanisms and media for storing data relating to a particular aspect ofthe present disclosure. For example, the data store illustrated mayinclude mechanisms for storing production data 3012 and user information3016, which can be used to serve content for the production side. Thedata store also is shown to include a mechanism for storing log data3014, which can be used for reporting, analysis, or other such purposes.It should be understood that there can be many other aspects that mayneed to be stored in the data store, such as page image information andaccess rights information, which can be stored in any of the abovelisted mechanisms as appropriate or in additional mechanisms in the datastore 3010. The data store 3010 is operable, through logic associatedtherewith, to receive instructions from the application server 3008 andobtain, update, or otherwise process data in response thereto. Theapplication server 3008 may provide static, dynamic, or a combination ofstatic and dynamic data in response to the received instructions.Dynamic data, such as data used in web logs (blogs), shoppingapplications, news services, and other such applications may begenerated by server-side structured languages as described herein or maybe provided by a content management system (“CMS”) operating on, orunder the control of, the application server. In one example, a user,through a device operated by the user, might submit a search request fora certain type of item. In this case, the data store might access theuser information to verify the identity of the user and can access thecatalog detail information to obtain information about items of thattype. The information then can be returned to the user, such as in aresults listing on a web page that the user is able to view via abrowser on the client device 3002. Information for a particular item ofinterest can be viewed in a dedicated page or window of the browser. Itshould be noted, however, that embodiments of the present disclosure arenot necessarily limited to the context of web pages, but may be moregenerally applicable to processing requests in general, where therequests are not necessarily requests for content.

Each server typically will include an operating system that providesexecutable program instructions for the general administration andoperation of that server and typically will include a computer-readablestorage medium (e.g., a hard disk, random access memory, read onlymemory, etc.) storing instructions that, when executed (i.e., as aresult of being executed) by a processor of the server, allow the serverto perform its intended functions.

The environment, in one embodiment, is a distributed and/or virtualcomputing environment utilizing several computer systems and componentsthat are interconnected via communication links, using one or morecomputer networks or direct connections. However, it will be appreciatedby those of ordinary skill in the art that such a system could operateequally well in a system having fewer or a greater number of componentsthan are illustrated in FIG. 30 . Thus, the depiction of the system 3000in FIG. 30 should be taken as being illustrative in nature and notlimiting to the scope of the disclosure.

The various embodiments further can be implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers, computing devices, or processing devices which can be used tooperate any of a number of applications. User or client devices caninclude any of a number of computers, such as desktop, laptop, or tabletcomputers running a standard operating system, as well as cellular,wireless, and handheld devices running mobile software and capable ofsupporting a number of networking and messaging protocols. Such a systemalso can include a number of workstations running any of a variety ofcommercially available operating systems and other known applicationsfor purposes such as development and database management. These devicesalso can include other electronic devices, such as dummy terminals,thin-clients, gaming systems, and other devices capable of communicatingvia a network. These devices also can include virtual devices such asvirtual machines, hypervisors, and other virtual devices capable ofcommunicating via a network.

Various embodiments of the present disclosure utilize at least onenetwork that would be familiar to those skilled in the art forsupporting communications using any of a variety of commerciallyavailable protocols, such as Transmission Control Protocol/InternetProtocol (“TCP/IP”), User Datagram Protocol (“UDP”), protocols operatingin various layers of the Open System Interconnection (“OSI”) model, FileTransfer Protocol (“FTP”), Universal Plug and Play (“UpnP”), NetworkFile System (“NFS”), Common Internet File System (“CIFS”), andAppleTalk. The network can be, for example, a local area network, awide-area network, a virtual private network, the Internet, an intranet,an extranet, a public switched telephone network, an infrared network, awireless network, a satellite network, and any combination thereof. Insome embodiments, connection-oriented protocols may be used tocommunicate between network endpoints. Connection-oriented protocols(sometimes called connection-based protocols) are capable oftransmitting data in an ordered stream. Connection-oriented protocolscan be reliable or unreliable. For example, the TCP protocol is areliable connection-oriented protocol. Asynchronous Transfer Mode(“ATM”) and Frame Relay are unreliable connection-oriented protocols.Connection-oriented protocols are in contrast to packet-orientedprotocols such as UDP that transmit packets without a guaranteedordering.

In embodiments utilizing a web server, the web server can run any of avariety of server or mid-tier applications, including Hypertext TransferProtocol (“HTTP”) servers, FTP servers, Common Gateway Interface (“CGI”)servers, data servers, Java servers, Apache servers, and businessapplication servers. The server(s) also may be capable of executingprograms or scripts in response to requests from user devices, such asby executing one or more web applications that may be implemented as oneor more scripts or programs written in any programming language, such asJava C, C#, or C++, or any scripting language, such as Ruby, PHP, Perl,Python, or TCL, as well as combinations thereof. The server(s) may alsoinclude database servers, including without limitation thosecommercially available from Oracle®, Microsoft®, Sybase®, and IBM® aswell as open-source servers such as MySQL, Postgres, SQLite, MongoDB,and any other server capable of storing, retrieving, and accessingstructured or unstructured data. Database servers may includetable-based servers, document-based servers, unstructured servers,relational servers, non-relational servers, or combinations of theseand/or other database servers.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (“SAN”) familiar to those skilledin the art. Similarly, any necessary files for performing the functionsattributed to the computers, servers or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (“CPU” or “processor”), atleast one input device (e.g., a mouse, keyboard, controller, touchscreen, or keypad), and at least one output device (e.g., a displaydevice, printer, or speaker). Such a system may also include one or morestorage devices, such as disk drives, optical storage devices, andsolid-state storage devices such as random access memory (“RAM”) orread-only memory (“ROM”), as well as removable media devices, memorycards, flash cards, etc.

Such devices also can include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired), an infrared communication device, etc.), and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium, representing remote, local, fixed, and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting, and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services, or other elementslocated within at least one working memory device, including anoperating system and application programs, such as a client applicationor web browser. In addition, customized hardware might also be usedand/or particular elements might be implemented in hardware, software(including portable software, such as applets), or both. Further,connection to other computing devices such as network input/outputdevices may be employed.

Storage media and computer readable media for containing code, orportions of code, can include any appropriate media known or used in theart, including storage media and communication media, such as, but notlimited to, volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage and/or transmissionof information such as computer readable instructions, data structures,program modules, or other data, including RAM, ROM, ElectricallyErasable Programmable Read-Only Memory (“EEPROM”), flash memory, orother memory technology, Compact Disc Read-Only Memory (“CD-ROM”),digital versatile disk (DVD), or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage, or other magneticstorage devices or any other medium which can be used to store thedesired information and which can be accessed by the system device.Based on the disclosure and teachings provided herein, a person ofordinary skill in the art will appreciate other ways and/or methods toimplement the various embodiments.

Example cryptographic algorithms include block ciphers and the variousmodes that utilize initialization vectors, such as the cipher-blockchaining (CBC) mode, propagating cipher-block chaining (PCBC) mode,cipher feedback mode (CFB), output feedback (OFB) mode, counter (CTR)mode, and other modes, such as authenticated encryption modes such aseXtended Ciphertext Block Chaining (XCBC) mode, Integrity Aware CBC(IACBC) mode, Integrity Aware Parallelizable (IAPM) mode, OffsetCodebook (OCB) mode, EAX and EAX Prime modes, Carter-Wegman+CTR (CWC)mode, Counter with CBC-MAC (CCM) mode, and Galois/Counter (GCM) mode.

As discussed, numerous variations utilize symmetric and/or asymmetriccryptographic primitives. Symmetric key algorithms may include variousschemes for performing cryptographic operations on data including blockciphers, stream ciphers, and digital signature schemes. Examplesymmetric key algorithms include the advanced encryption standard (AES),the data encryption standard (DES), triple DES (3DES), Serpent, Twofish,blowfish, CASTS, RC4, and the international data encryption algorithm(IDEA). Symmetric key algorithms may also include those used to generateoutput of one way functions and include algorithms that utilizehash-based message authentication codes (HMACs), message authenticationcodes (MACs) in general, PBKDF2 and Bcrypt. Asymmetric key algorithmsmay also include various schemes for performing cryptographic operationson data. Example algorithms include those that utilize theDiffie-Hellman key exchange protocol, the digital signature standard(DSS), the digital signature algorithm, the ElGamal algorithm, variouselliptic curve algorithms, password-authenticated key agreementtechniques, the pallier cryptosystem, the RSA encryption algorithm (PKCS#1), the Cramer-Shoup cryptosystem, the YAK authenticated key agreementprotocol, the NTRUEncrypt cryptosystem, the McEliece cryptosystem, andothers. Elliptic curve algorithms include the elliptic curveDiffie-Hellman (ECDH) key agreement scheme, the Elliptic CurveIntegrated Encryption Scheme (ECIES), the Elliptic Curve DigitalSignature Algorithm (ECDSA), the ECMQV key agreement scheme, and theECQV implicit certificate scheme. Other algorithms and combinations ofalgorithms are also considered as being within the scope of the presentdisclosure and the above is not intended to be an exhaustive list.

Note that the term “digital signature” includes any information usableto cryptographically verify authenticity of a message includinginformation generated using an RSA-based digital scheme (such asRSA-PSS), the digital signature algorithm (DSA), and the elliptic curvedigital signature algorithm, the ElGamal signature scheme, the Schnorrsignature scheme, the Pointcheval-Stern signature algorithm, the Rabinsignature algorithm, pairing-based digital signature schemes (such asthe Boneh-Lynn-Schacham signature scheme), undeniable digital signatureschemes, and others. Further, message authentication codes (such ashash-based message authentication codes (HMACs), keyed cryptographichash functions, and other types of information may also be used asdigital signatures.

It should be noted that the phrase “one-way function” includes functionsthat are not necessarily one-way in the strict mathematical sense, butthat exhibit properties (such as collision resistance, preimageresistance and second preimage resistance) that render the functionuseful in contexts in which the various techniques of the presentdisclosure are applied. In this manner, an entity with output of thefunction but without access to the corresponding input, is unable todetermine the input without, for instance, extraordinary expenditure ofcomputational resources necessary for a cryptographic (e.g., bruteforce) attack. One-way functions (also referred to as “effectivelyone-way functions”) include, but are not limited to, cryptographic hashfunctions such as message authentication codes, (e.g., hash basedmessage authentication code (HMAC)), key derivation functions, such asPBKDF2 and bcrypt (with the password being based at least in part on theplaintext and the cryptographic key, e.g.) and other securerandomization functions which may, but do not necessarily, have a domain(set of possible inputs) that is larger than their range (possibleoutputs). Other suitable functions (referred to as “f”) for variousembodiments include, but are not limited to, functions that take atleast a plaintext and cryptographic key as input and that have aproperty of preimage resistance (given a value y, the probability ofrandomly generating an input x such that f(x)=y is below a specifiedthreshold), second preimage resistance (given an input x1, the probablyof randomly generating another input x2, different from x1, such thatf(x1)=f(x2) is below a specified threshold) and/or collision resistance(the probability of two different inputs resulting in the same output isless than a specified threshold). The exact threshold for eachprobability may be context-dependent, with lower probabilitiescorresponding to higher security contexts. Hash functions usable asone-way functions in accordance with the techniques of the presentdisclosure include, but are not limited to, functions described in theNational Institute of Standards and Technology (NIST) SpecialPublication 800-107, Revision 1 “Recommendation for Applications UsingApproved Hash Algorithms,” which is incorporated herein by reference.

Note that a system is said to be configured to trust a publiccryptographic key if logic with which the system is configured tooperate is dependent on whether an attempt to verify a digital signaturewith the public cryptographic key is successful. Similarly, a system issaid to be configured to trust a symmetric cryptographic key if logicwith which the system is configured to operate is dependent on whetheran attempt to verify a digital signature with the symmetriccryptographic key is successful.

In various embodiments, data objects such as digital signatures may becryptographically verifiable. In one example, cryptographicallyverifiable data objects are created to be cryptographically verifiableby the system to which the data object is to be provided or anothersystem that operates in conjunction with the system to which the dataobject is to be provided. For example, the data object may be encryptedso as to be decryptable by the system that will cryptographically verifythe data object, where the ability to decrypt the data object serves ascryptographic verification of the data object. As another example, thedata object may be digitally signed (thereby producing a digitalsignature of the data object) such that the digital signature isverifiable by the system that will cryptographically verify the dataobject. In other examples, both encryption and digital signatures areused for cryptographic verifiability and/or security. The key used toencrypt and/or digitally sign the data object may vary in accordancewith various embodiments and the same key is not necessarily used forboth encryption and digital signing, where applicable. In someembodiments, a key used to encrypt the data object is a public key of apublic/private key pair where the private key of the key pair ismaintained securely by the system to which the data object is to beprovided, thereby enabling the system to decrypt the data object usingthe private key of the key pair. Using the public key to encrypt thedata object may include generating a symmetric key, using the symmetrickey to encrypt the data object, and encrypting the symmetric key usingthe public key, where the encrypted symmetric key is provided to asystem with the encrypted data object to enable the system to use thecorresponding private key to decrypt the symmetric key and use thedecrypted symmetric key to decrypt the data object. Further, in someembodiments, the data object is digitally signed using a private key ofa public/private key pair corresponding to the computer system thatencrypts and/or digitally signs the data object (e.g., a user device).For example, an application may be provisioned with the private key andthe data object may include a certificate for the private key for use bya system for verification of the digital signature of the data object.Other variations, including variations where a symmetric key sharedbetween the user computer and the system that cryptographically verifiesthe data object can be used to encrypt and/or digitally sign the dataobject.

In the preceding and following description, various techniques aredescribed. For purposes of explanation, specific configurations anddetails are set forth in order to provide a thorough understanding ofpossible ways of implementing the techniques. However, it will also beapparent that the techniques described below may be practiced indifferent configurations without the specific details. Furthermore,well-known features may be omitted or simplified to avoid obscuring thetechniques being described.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

Other variations are within the spirit of the present disclosure. Thus,while the disclosed techniques are susceptible to various modificationsand alternative constructions, certain illustrated embodiments thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific form or forms disclosed, but on the contrary,the intention is to cover all modifications, alternative constructions,and equivalents falling within the spirit and scope of the invention, asdefined in the appended claims.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosed embodiments (especially in thecontext of the following claims) are to be construed to cover both thesingular and the plural, unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including,”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. The term“connected,” when unmodified and referring to physical connections, isto be construed as partly or wholly contained within, attached to, orjoined together, even if there is something intervening. Recitation ofranges of values herein are merely intended to serve as a shorthandmethod of referring individually to each separate value falling withinthe range, unless otherwise indicated herein and each separate value isincorporated into the specification as if it were individually recitedherein. The use of the term “set” (e.g., “a set of items”) or “subset”unless otherwise noted or contradicted by context, is to be construed asa nonempty collection comprising one or more members. Further, unlessotherwise noted or contradicted by context, the term “subset” of acorresponding set does not necessarily denote a proper subset of thecorresponding set, but the subset and the corresponding set may beequal.

Conjunctive language, such as phrases of the form “at least one of A, B,and C,” or “at least one of A, B and C,” unless specifically statedotherwise or otherwise clearly contradicted by context, is otherwiseunderstood with the context as used in general to present that an item,term, etc., may be either A or B or C, or any nonempty subset of the setof A and B and C. For instance, in the illustrative example of a sethaving three members, the conjunctive phrases “at least one of A, B, andC” and “at least one of A, B and C” refer to any of the following sets:{A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunctivelanguage is not generally intended to imply that certain embodimentsrequire at least one of A, at least one of B and at least one of C eachto be present.

Operations of processes described herein can be performed in anysuitable order unless otherwise indicated herein or otherwise clearlycontradicted by context. Processes described herein (or variationsand/or combinations thereof) may be performed under the control of oneor more computer systems configured with executable instructions and maybe implemented as code (e.g., executable instructions, one or morecomputer programs or one or more applications) executing collectively onone or more processors, by hardware or combinations thereof. The codemay be stored on a computer-readable storage medium, for example, in theform of a computer program comprising a plurality of instructionsexecutable by one or more processors. The computer-readable storagemedium may be non-transitory. In some embodiments, the code is stored onset of one or more non-transitory computer-readable storage media havingstored thereon executable instructions that, when executed (i.e., as aresult of being executed) by one or more processors of a computersystem, cause the computer system to perform operations describedherein. The set of non-transitory computer-readable storage media maycomprise multiple non-transitory computer-readable storage media and oneor more of individual non-transitory storage media of the multiplenon-transitory computer-readable storage media may lack all of the codewhile the multiple non-transitory computer-readable storage mediacollectively store all of the code. Further, in some examples, theexecutable instructions are executed such that different instructionsare executed by different processors. As an illustrative example, anon-transitory computer-readable storage medium may store instructions.A main CPU may execute some of the instructions and a graphics processorunit may execute other of the instructions. Generally, differentcomponents of a computer system may have separate processors anddifferent processors may execute different subsets of the instructions.

Accordingly, in some examples, computer systems are configured toimplement one or more services that singly or collectively performoperations of processes described herein. Such computer systems may, forinstance, be configured with applicable hardware and/or software thatenable the performance of the operations. Further, computer systems thatimplement various embodiments of the present disclosure may, in someexamples, be single devices and, in other examples, be distributedcomputer systems comprising multiple devices that operate differentlysuch that the distributed computer system performs the operationsdescribed herein and such that a single device may not perform alloperations.

The use of any and all examples, or exemplary language (e.g., “such as”)provided herein, is intended merely to better illuminate embodiments ofthe invention and does not pose a limitation on the scope of theinvention unless otherwise claimed. No language in the specificationshould be construed as indicating any non-claimed element as essentialto the practice of the invention.

Embodiments of this disclosure are described herein, including the bestmode known to the inventors for carrying out the invention. Variationsof those embodiments may become apparent to those of ordinary skill inthe art upon reading the foregoing description. The inventors expectskilled artisans to employ such variations as appropriate and theinventors intend for embodiments of the present disclosure to bepracticed otherwise than as specifically described herein. Accordingly,the scope of the present disclosure includes all modifications andequivalents of the subject matter recited in the claims appended heretoas permitted by applicable law. Moreover, any combination of theabove-described elements in all possible variations thereof isencompassed by the scope of the present disclosure unless otherwiseindicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications, andpatents, cited herein are hereby incorporated by reference to the sameextent as if each reference were individually and specifically indicatedto be incorporated by reference and were set forth in its entiretyherein.

What is claimed is:
 1. A computer-implemented method, comprising:acquiring a digital signature of a message; identifying a cryptographickey used to generate the digital signature; requesting, from a signatureauthority, proof that the cryptographic key is valid; receiving, from akey revocation service that is delegated authority to revoke thecryptographic key by the signature authority, a revocation value and anindication that the cryptographic key is revoked; cryptographicallyderiving a verification hash from a combination of a cryptographic hashof the revocation value and a cryptographic hash of a public portion ofthe cryptographic key; and confirming that the cryptographic key isrevoked by verifying the verification hash against a public key of thesignature authority that generated the cryptographic key using a hashtree generated under authority of the signature authority.
 2. Thecomputer-implemented method of claim 1, wherein the key revocationservice is provided by the signature authority.
 3. Thecomputer-implemented method of claim 1, wherein: the hash tree isgenerated from a set of hashes generated from a set of cryptographickeys that include the cryptographic key; and a root of the hash tree isthe public key of the signature authority.
 4. The computer-implementedmethod of claim 3, wherein: the combination of the cryptographic hash ofthe revocation value and the cryptographic hash of the public portion ofthe cryptographic key is further combined with at least one additionalnode of the hash tree; the verification hash is associated with anon-leaf node of the hash tree; and the revocation value proves therevocation of a plurality of cryptographic keys of the set ofcryptographic keys.
 5. A system, comprising: at least one computingdevice coupled to a processor and a memory containing instructions that,as a result of being executed, implement one or more services that:acquire a digital signature; identify a cryptographic key used togenerate the digital signature; request, from a signature authority,proof that the cryptographic key is valid; receive, from the signatureauthority, a revocation value and an indication that the cryptographickey is revoked; cryptographically derive a verification hash based onthe revocation value and a public portion of the cryptographic key; andconfirm that the cryptographic key is revoked by verifying theverification hash against a public key of the signature authority thatgenerated the cryptographic key.
 6. The system of claim 5, wherein theone or more services further: request, from a confirmation authority,proof that the cryptographic key is not revoked; receive, from theconfirmation authority, a confirmation value; generate a confirmationhash by determining a hash of a combination of the cryptographic hash ofthe revocation value and the cryptographic hash of the public portion ofthe cryptographic key and a cryptographic hash of the confirmationvalue; and confirm that the cryptographic key has not been revoked byverifying the confirmation hash against the public key of the signatureauthority that generated the cryptographic key.
 7. The system of claim5, wherein the one or more services further: receive the cryptographickey from the signature authority; and generate the digital signatureusing the cryptographic key.
 8. The system of claim 5, whereincryptographically deriving the verification hash is based on thecombination of a cryptographic hash of the revocation value and acryptographic hash of the public portion of the cryptographic key. 9.The system of claim 8, wherein: the verification hash is a hash within ahash tree generated by the signature authority; the hash tree isgenerated based on a set of cryptographic keys that include thecryptographic key; and a root of the hash tree is the public key of thesignature authority.
 10. The system of claim 9, wherein: the combinationof the cryptographic hash of the revocation value and the cryptographichash of the public portion of the cryptographic key is further combinedwith at least one additional node of the hash tree; and the revocationvalue proves the revocation of only one cryptographic key of the set ofcryptographic keys.
 11. The system of claim 5, wherein the one or moreservices further: request, from a confirmation authority, proof that thecryptographic key is revoked; receive, from the confirmation authority,a confirmation value; generate a confirmation hash by determining a hashof a combination of the cryptographic hash of the revocation value andthe cryptographic hash of the public portion of the cryptographic keyand a cryptographic hash of the confirmation value; and confirm that thecryptographic key is revoked by verifying the confirmation hash againstthe public key of the signature authority that generated thecryptographic key.
 12. The system of claim 11, wherein the one or moreservices further: as a result of receiving the indication that thecryptographic key is revoked, receive a new cryptographic key from thesignature authority; and generate a new digital signature based on thenew cryptographic key.
 13. A non-transitory computer-readable storagemedium having stored thereon executable instructions that, as a resultof being executed by one or more processors of at least one computersystem, cause the computer system to at least: acquire a digitalsignature associated with a message; identify a cryptographic key usedto generate the digital signature; request, from a signature authority,proof that the cryptographic key is valid; receive, from the signatureauthority, a revocation value and an indication that the cryptographickey is revoked; cryptographically derive a verification hash from acombination of a cryptographic hash of the revocation value and acryptographic hash of a public portion of the cryptographic key; andconfirm that the cryptographic key is revoked by verifying theverification hash against a public key of the signature authority thatgenerated the cryptographic key.
 14. The non-transitorycomputer-readable storage medium of claim 13, wherein the instructionsfurther comprise instructions that, as a result of being executed by theone or more processors, cause the computer system to: request, from aconfirmation authority, proof that the cryptographic key is revoked;receive, from the confirmation authority, a confirmation value; generatea confirmation hash by determining a hash of a combination of thecryptographic hash of the revocation value and the cryptographic hash ofthe public portion of the cryptographic key and a cryptographic hash ofthe confirmation value; and confirm that the cryptographic key isrevoked by verifying the confirmation hash against the public key of thesignature authority that generated the cryptographic key.
 15. Thenon-transitory computer-readable storage medium of claim 13, wherein theinstructions further comprise instructions that, as a result of beingexecuted by the one or more processors, cause the computer system to:request, from a confirmation authority, proof that the cryptographic keyis not revoked; receive, from the confirmation authority, a confirmationvalue; generate a confirmation hash by determining a hash of acombination of the cryptographic hash of the revocation value and thecryptographic hash of the public portion of the cryptographic key and acryptographic hash of the confirmation value; and confirm thatrevocation of the cryptographic key is rescinded by verifying theconfirmation hash against the public key of the signature authority thatgenerated the cryptographic key.
 16. The non-transitorycomputer-readable storage medium of claim 13, wherein the instructionsfurther comprise instructions that, as a result of being executed by theone or more processors, cause the computer system to: as a result ofreceiving the indication that the cryptographic key is revoked, receivea new cryptographic key from the signature authority; and generate a newdigital signature for the message.
 17. The non-transitorycomputer-readable storage medium of claim 13, wherein the instructionsfurther comprise instructions that, as a result of being executed by theone or more processors, cause the computer system to: receive thecryptographic key from the signature authority; and generate a digitalsignature of the message using the cryptographic key.
 18. Thenon-transitory computer-readable storage medium of claim 13, wherein:the signature authority is a service running on a remote computersystem; a request for proof that the cryptographic key is valid issubmitted to the service running on the remote computer system via anetwork service interface; and the revocation value is received as aresponse to the request via the network service interface.
 19. Thenon-transitory computer-readable storage medium of claim 13, wherein:the verification hash is a hash within a hash tree generated by thesignature authority; the hash tree is generated from a set of hashesgenerated from a set of cryptographic keys that include thecryptographic key; and a root of the hash tree is the public key of thesignature authority.
 20. The non-transitory computer-readable storagemedium of claim 19, wherein: the combination of the cryptographic hashof the revocation value and the cryptographic hash of the public portionof the cryptographic key is further combined with at least oneadditional node of the hash tree; the verification hash is associatedwith a non-leaf node of the hash tree; and the revocation value provesthe revocation of a plurality of cryptographic keys of the set ofcryptographic keys.